libera/commonlisp - IRC Chatlog
Search
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.
21:25:05
jackdaniel
when you have a somewhat large data structure that you know that it does not escape the dynamic extent
21:25:54
jackdaniel
of course the compiler may ignore that declaration whatsoever and go straight to the heap with it
21:26:31
dbotton
I think I am having difficult understanding then when it would be deallocated off the stack
21:27:44
Nilby
Yes. Dynamic extent says the thing won't be used after the function returns. The details of the exact optimization can change
21:28:47
jackdaniel
#2 is invalid (as Bike pointed out), but nothing will crash, because that data is not allocated on the stack
21:30:23
jackdaniel
some implementations may decide to ignore the declaration /unless/ they can formally prove that the value does not escape
21:30:46
jackdaniel
other implementations may trust you and then gleefully have a segmentation fault
21:35:04
jackdaniel
(defun xxx (a) (print a)) (defun yyy () (let ((foo (list 1 2))) (declare (dynamic-extent foo)) (xxx (list* 1 foo)))))
21:35:43
jackdaniel
the list named foo in yyy is available in xxx (and xxx is invoked in the dynamic extent of yyy), but foo is not available for xxx by name
21:38:41
jackdaniel
of course what I did is an undefined behavior, because print returns its argument, and I'm returning the result of xxx, but that's beside the point
21:42:04
Nilby
I don't want to add confusion, but print could call a print-object method that steals the object too.
21:43:38
dbotton
so if you are hinting dynamic-extent to compiler you should tell users of your function not to "steal" your object
21:44:55
jackdaniel
you should not let escape variables with dynamic extent to escape, in other words you should not call functions that may capture the variable outside of it