Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minimal extension for ,. syntax #79

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

yitzchak
Copy link
Member

@yitzchak yitzchak commented Sep 28, 2023

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-splicing and making the default for wrap-in-unquote-nsplicing be the appropriate specialization of wrap-in-unquote-splicing.

Obviously, error messages, tests, etc. could be updated.

FYI @Bike

@scymtym
Copy link
Member

scymtym commented Oct 2, 2023

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 (make-{structure-instance,…} client …)(make-literal client :structure-instance …), (make-literal client 'float :type 'double-float :sign …), (make-literal client 'hash-table …) and (wrap-in-{function,quote,unquote,unquote-splicing} client …)(wrap-in client :unquote … :splicing t :destructive t)`.

@yitzchak
Copy link
Member Author

yitzchak commented Oct 2, 2023

I understand either way.

I do like the make-* pattern a lot more. Also, using keys as arguments like (wrap-in client :unquote … :splicing t :destructive t) prevents specialization on those values. I would suggest something like (make-form client :unquote-nsplicing form)

@scymtym
Copy link
Member

scymtym commented Oct 2, 2023

I do like the make-* pattern a lot more.

Can you please clarify? Do yo prefer separate functions make-structure-instance, … over a single function make-literal or do you prefer the change make-structure-instance, … → make-literal over the change wrap-in-quote, … → wrap-in

Also, using keys as arguments like (wrap-in client :unquote … :splicing t :destructive t) prevents specialization on those values. I would suggest something like (make-form client :unquote-nsplicing form)

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 (wrap-in client *unquote-nsplicing* form). This would allow the client to specialize to both all unquote variants (or even all wrapping variants) or specific ones.

@yitzchak
Copy link
Member Author

yitzchak commented Oct 2, 2023

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 (unquote bla).

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.

@scymtym scymtym added the enhancement New feature or request label Oct 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants