In CLISP, in a nested backquote, you can splice items into a quote
using ,',@items.

This ends up working like ,@',items. It's as if the quote distributes
through the splice and the items are individually quoted and spliced.

In other implementations like SBCL and ECL, this just produces
an invalid quote form like (quote 1 2 3 4) which is an error.
Except in the lucky case when there is one item, of course.

Where else other than CLISP does that work?

According to my interpretation of 2.4.6 Backquote, the behavior does
not arise from that expansion model.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @[email protected]
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In other implementations like SBCL and ECL, this just produces
an invalid quote form like (quote 1 2 3 4) which is an error.
Except in the lucky case when there is one item, of course.

Would it make sense to define (quote 1 2 3 4) as behaving like
(values 1 2 3 4)?


Stefan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-12-04, Stefan Monnier <[email protected]> wrote:

In other implementations like SBCL and ECL, this just produces
an invalid quote form like (quote 1 2 3 4) which is an error.
Except in the lucky case when there is one item, of course.

Would it make sense to define (quote 1 2 3 4) as behaving like
(values 1 2 3 4)?

It's certainly more useful than signaling an error.

It's not directly related to the topic I started (which I don't mind)
unless we make ,(values 1 2 3) equivalent to ,@'(1 2 3)
and ,@(list 1 2 3).

Then we could have it that ,(quote 1 2 3) is like ,@(list 1 2 3).

Splicing values would break existing code which relies on
,(values 1 2 3) behaving like ,1 and ,(values) behaving like nil.

In CLISP, though, the multi-argument quote, if it is produced
by a splice, and being unquoted, does distribute, so that
,(quote ,@(list 1 2 3)) becomes, effectively ,1 ,2 ,3.

Without the quote ,,@expr follows a distributive rule in that
expr evaluates to some list of elements e0 e1 e2 ...
and these are individually unquoted in the second round as if
by ,e1 ,e2 ,e3 ...

In CLISP, even if there is a quote between the , and ,@,
the distribution occurs, carrying duplicates of the quote, so that
,(quote ,@expr) turns into, effectively ,'e1 ,'e2 ,'e3 ...

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @[email protected]
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

* Kaz Kylheku <20231204193336.389 @kylheku.com> :
Wrote on Tue, 5 Dec 2023 03:44:45 -0000 (UTC):

On 2023-12-04, Stefan Monnier <[email protected]> wrote:

In other implementations like SBCL and ECL, this just produces
an invalid quote form like (quote 1 2 3 4) which is an error.
Except in the lucky case when there is one item, of course.

I think lispworks just the above form as a list of 1 element (in the
"spliced contenxt") and avoids an error on the form previously, but
don't quote me on that.

Would it make sense to define (quote 1 2 3 4) as behaving like
(values 1 2 3 4)?

LW seemed to do just that, when operating in that context (but I haven't rechecked to be sure)

It's certainly more useful than signaling an error.

It's not directly related to the topic I started (which I don't mind)
unless we make ,(values 1 2 3) equivalent to ,@'(1 2 3)
and ,@(list 1 2 3).

Then we could have it that ,(quote 1 2 3) is like ,@(list 1 2 3).

Splicing values would break existing code which relies on
,(values 1 2 3) behaving like ,1 and ,(values) behaving like nil.

In CLISP, though, the multi-argument quote, if it is produced
by a splice, and being unquoted, does distribute, so that
,(quote ,@(list 1 2 3)) becomes, effectively ,1 ,2 ,3.

I think I relied on this "intuitive behaviour" in clisp at some point
and had to unlearn it to be able to use other lisps.

Without the quote ,,@expr follows a distributive rule in that
expr evaluates to some list of elements e0 e1 e2 ...
and these are individually unquoted in the second round as if
by ,e1 ,e2 ,e3 ...

In CLISP, even if there is a quote between the , and ,@,
the distribution occurs, carrying duplicates of the quote, so that
,(quote ,@expr) turns into, effectively ,'e1 ,'e2 ,'e3 ...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)