libera/commonlisp - IRC Chatlog
Search
9:27:51
pve
Good morning! Continuing the theme of file-local things, I wanted to see if symbols can be made file-local. Here's an example of what I got:
9:32:09
pve
But the hyperspec page for the reader algorithm says that "The reader macro function must not have any side effects other than on the input stream...", and I'm not entirely sure how to interpret that.
9:43:26
pve
beach: the reader collects the file-local symbols into a table as it goes through the file, and replaces the occurrences with uninterned symbols.
9:44:48
beach
Yes, I also think it is a side effect. How does that work if the symbol ends with the special character?
9:52:42
pve
beach: when it encounters "%FOO" for the first time it adds an "%FOO" -> #:FOO entry to a hash table, on subsequent occurrences it uses that same uninterned symbol
9:53:37
beach
I was asking specifically for the case when the special character is at the end of the name. And I am asking how you program the reader to do that.
9:54:22
Nilby
pve: The standard reader macros have side effects, so the hyperspec is being a little hypocritical. It's probably good to make sure reader macros don't have _unintended_ side effects, but I think every CL allows it.
9:54:59
pve
beach: oh, I use (alexandria:ends-with "%" (symbol-name sym)), if that's what you mean..
9:57:42
pve
beach: oh ok, with-symbol-expansion sets up the readtable that "intercepts" the standard reader for all "standard" characters
9:58:36
beach
Too bad you are not using Eclector. It would be much simpler, and you would not need to violate the restrictions of the standard.
10:00:05
beach
But I guess you want this thing to work with the default reader of the Common Lisp implementation.
10:00:51
beach
Then let me change to "Too bad all major Common Lisp implementations are using a reader other than Eclector".
10:05:31
pve
beach: If I were to use eclector, I think I would still need to intercept the standard reader for all characters to redirect to eclector at the beginning of the file. Unless some asdf voodoo can be done to change how a file is loaded (I think I would rather load with CL:LOAD).
10:08:53
beach
Yes, I don't think you can change what reader CL:LOAD uses. But that would be handy if it were possible.
10:14:57
pve
But regardless of the choice of reader, I think it's pretty neat that helper functions or special variables can be made file-local. I, at least, sometimes have trouble coming up with names for helper functions because I usually want them to be short (like with flet or labels), but at the same time they can't be too short because the (perceived) risk of clobbering other functions grow bigger. I know this
10:15:34
beach
jackdaniel: "pushy"? I meant that just as a reiteration of my well known position, i.e., that there is a lot of duplicate effort in the Common Lisp community, and we are already short of peoplepower.
10:17:37
jackdaniel
hm, let me elaborate: surely creating yet another reader reduces the the amount of duplicated effort; by pushy I mean that you reiterate your well known position (that imlementations should replace their own modules with your clearly better ones) quite frequently
10:19:02
beach
Eclector is not just another reader. It can do things that no standard reader of any existing implementation can do.
10:20:37
_death
pve: I often use package-inferred-system style, where each file defines its own package.. this removes the anxiety of choosing such internal names
10:23:09
Nilby
Eclector is actually harder to use the standard reader, and can't function as a standard reader without the "client" supplying a number of pieces. Recommending it for things the implementation's reader can do seems inappropriate.
10:25:02
pve
_death: I go back and forth on package-inferred style, but I it does help with the anxiety for sure.
10:31:35
Nilby
On the other hand, the standard reader is missing one crucial feature from Lisp Machine Lisps that makes it impossible to do a number a very useful things.
10:33:46
_death
pve: it has the added advantage that nothing out of the ordinary (for a CL programmer) is going on..
10:41:57
Nilby
beach: I'm not trying to pick on Eclector. I think it's great to have a fully customizable reader. But it can be tricky to use, especially for replacing the implementation's version.
10:43:56
pve
_death: But sometimes I feel that there's a tiny bit too much friction with the package-inferred style if I'm just exploring (like frequently changing export lists). I dunno, maybe you know what I mean, or maybe it's just me.
10:45:10
pve
If the experience could be made smoother somehow (opinionated is fine), I might be all over it. But this could be a case of having my cake and eating it.
10:49:32
pve
like sometimes I know I want to USE everything in another file, except the helper functions, and figure out the exports later.
10:56:27
_death
well, in tests and experimental code I sometimes use :: until I figure it out.. I don't mind it because it's the same project
11:00:04
_death
and when the right interface to export comes up, removing those ::s feels good.. so win-win :)
11:01:09
pve
wait a minute, couldn't I just automatically export everything that's bound to something unless the symbol contains, say, "%"?
11:05:28
_death
to me #\% and other such nuisance chars are too distasteful to use in names.. *foo* is as far as I go
15:18:43
jcowan
As for license changes: take a look at the license of Python some time. Most of it is junk DNA that is carried around by the requirement not to strip the license text.
15:28:05
jcowan
That we have so much overlap because nobody is willing to say "I will include stuff in this library for which I myself have no use"
15:38:47
Shinmera
A similar reason that I *do* see is that it often feels like getting changes into an existing project is more effort than just writing a new solution. Or in the very least, it is much less appealing to do so.