Minimal extension for ,. syntax#79
Conversation
|
I'm not opposed to adding this for now. However, in the long run, I would like to turn several groups of related functions into more extensible protocols. For example something like |
|
I understand either way. I do like the |
Can you please clarify? Do yo prefer separate functions
I haven't thought about the design at this level of detail. In any case, one additional possibility would be something like (defclass any-wrapping () ())
(defclass any-unquote (any-wrapping) ())
(defclass any-unquote-splicing (any-unquote) ())
(defclass unquote-nsplicing (any-unquote-splicing) ())
(defvar *unquote-nsplicing* (make-instance 'unquote-nsplicing))with calls of the form |
|
I meant that I find the "wrap-in-*" naming to be a bit strange. I prefer "make-*" since it doesn't create implications as to how the thing is created. For example, SBCL creates a structure for unquote, whereas ECL, CLASP, CLISP and Mezzano all create something like I don't personally have a preference about multiple functions. I do really like your idea about using a class hierarchy for things like unquote. That's pretty clever. |
We have just added specializations of the
wrap-in-quote...generics to Clasp's eclector-client. Clasp does have destructive splicing (as rare as that is) but,.gets turned into,@by Eclector,This PR is an idea for a minimal extension to enable destructive splicing without changing the signature of
wrap-in-unquote-splicingand making the default forwrap-in-unquote-nsplicingbe the appropriate specialization ofwrap-in-unquote-splicing.Obviously, error messages, tests, etc. could be updated.
FYI @Bike