bug#34975: 26.1.92; In backquote, the comma marker does not work with variable name started with dot

bug#34975: 26.1.92; In backquote, the comma marker does not work with variable name started with dot

[Xu Chunyang]

For example,

(let ((.foo 42))
  (list .foo))
;; => (42)

(let ((.foo 42))
  `(,.foo))
;; => ((\,\. foo))

I expect both of them returns (42). is it a bug?

The bug report is inspired by https://www.reddit.com/r/emacs/comments/b325ae/letplist_a_version_of_the_useful_letalist_macro/

bug#34975: 26.1.92; In backquote, the comma marker does not work with variable name started with dot

[Michael Heerdegen]

Xu Chunyang <mail@xuchunyang.me> writes:

> For example,
>
> (let ((.foo 42))
>   (list .foo))
> ;; => (42)
>
> (let ((.foo 42))
>   `(,.foo))
> ;; => ((\,\. foo))
>
> I expect both of them returns (42). is it a bug?

AFAIU ,. is a reader macro:

(car (read ",.foo"))

  ==> \,\.

I dunno or have forgotten for what it had been intended, there are no
real uses in the Emacs Elisp sources.

> (let ((.foo 42))
>   `(,.foo))

You would have to write it differently, e.g.

(let ((.foo 42))
  `((\, .foo)))

  ==> (42)


Michael.

bug#34975: 26.1.92; In backquote, the comma marker does not work with variable name started with dot

[Drew Adams]

> AFAIU ,. is a reader macro: (car (read ",.foo"))
>   ==> \,\.
> 
> I dunno or have forgotten for what it had been intended, there are no
> real uses in the Emacs Elisp sources.
> 
> > (let ((.foo 42)) `(,.foo))

Yes, it's intended.  It acts the same as ,@

I might use it instead of ,@ to convey (to a human)
a connotation that what follows is not a proper list
(or is not necessarily a proper list), whereas ,@ is
typically thought of as splicing in a list of elements.

(I don't in fact use it, apparently, but I thought I
might have, and if I did use it instead of ,@ then it
would no doubt be for that reason.)

On the other hand, Common Lisp says that ,. has this
difference in meaning from ,@:

"Anywhere ``,@'' may be used, the syntax ``,.'' may
be used instead to indicate that it is permissible
to destroy the list produced by the form following
the ``,.''; this may permit more efficient code,
using nconc instead of append, for example."

https://www.cs.cmu.edu/Groups/AI/util/html/cltl/clm/node190.html#BACKQUOTE
 
> You would have to write it differently, e.g.
> 
> (let ((.foo 42)) `((\, .foo)))
>   ==> (42)

Yes.

bug#34975: 26.1.92; In backquote, the comma marker does not work with variable name started with dot

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> > I dunno or have forgotten for what it had been intended, there are no
> > real uses in the Emacs Elisp sources.
> >
> > > (let ((.foo 42)) `(,.foo))
>
> Yes, it's intended.  It acts the same as ,@
>
> I might use it instead of ,@ to convey (to a human)
> a connotation that what follows is not a proper list
> (or is not necessarily a proper list), whereas ,@ is
> typically thought of as splicing in a list of elements.
>
> (I don't in fact use it, apparently, but I thought I
> might have, and if I did use it instead of ,@ then it
> would no doubt be for that reason.)
>
> On the other hand, Common Lisp says that ,. has this
> difference in meaning from ,@:
>
> "Anywhere ``,@'' may be used, the syntax ``,.'' may
> be used instead to indicate that it is permissible
> to destroy the list produced by the form following
> the ``,.''; this may permit more efficient code,
> using nconc instead of append, for example."

Yes, thanks.  I also found that post:

https://lists.gnu.org/archive/html/emacs-devel/2012-02/msg00330.html

The state is the same as back then: ,. is a reader macro in Emacs Lisp,
but the head of the expansion (the symbol named ",.") doesn't have any
semantics, even not in backquote.

Michael.

bug#34975: 26.1.92; In backquote, the comma marker does not work with variable name started with dot

[Drew Adams]

> Yes, thanks.  I also found that post:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__lists.gnu.org_archive_html_emacs-2Ddevel_2012-
> 2D02_msg00330.html&d=DwIFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=k
> I3P6ljGv6CTHIKju0jqInF6AOwMCYRDQUmqX22rJ98&m=CxM0DPMvIA0IaOjx7pLPUAWhhKla65XR
> UOtlWoUp1pM&s=3ooHHbORUe59GfFU53KZE6gD6KNQLvxSeAKZuHs8TT8&e=
> 
> The state is the same as back then: ,. is a reader macro in Emacs Lisp,
> but the head of the expansion (the symbol named ",.") doesn't have any
> semantics, even not in backquote.

You're right; I was wrong.  I thought it did what
,@ does (which it should, whether or not it has the
extra difference of behavior specified for CL).

What it does in Emacs Lisp is _completely_ wrong, IMO.

(setq c 42)         ; c = 42
(setq a `(b ,. c))  ; a = (b (\,\. c))

bug#34975: 26.1.92; In backquote, the comma marker does not work with variable name started with dot

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> What it does in Emacs Lisp is _completely_ wrong, IMO.
>
> (setq c 42)         ; c = 42
> (setq a `(b ,. c))  ; a = (b (\,\. c))

Well, apart from the reader macro part, is has just never been
implemented.

I would already be happier if the current semantics of backquote would
be specified clearer in the docs: What happens with unquoted lists?
E.g.

(macroexpand '`(1 ,@x 3 ,@y))

 ==>
 (cons 1
      (append x
              '(3)
              y))

X is copied when evalling that, so the list stored in X is not modified
(good).  OTOH Y is not copied.  It's not necessary to copy the list
stored in Y to compute the value of the backquote expression without
modifying Y, so that's also ok.

But if you destructively modify the result of the backquote expression,
you may also change Y destructively (but not X).  Things like these
might be clear if you come from Common Lisp, but it's all not obvious
IMHO.


Michael.

bug#34975: 26.1.92; In backquote, the comma marker does not work with variable name started with dot

[Andreas Schwab]

On Mär 26 2019, Michael Heerdegen <michael_heerdegen@web.de> wrote:

> But if you destructively modify the result of the backquote expression,
> you may also change Y destructively (but not X).  Things like these
> might be clear if you come from Common Lisp, but it's all not obvious
> IMHO.

You need always be careful when destructively modifying structures,
independent of how they were computed.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

bug#34975: 26.1.92; In backquote, the comma marker does not work with variable name started with dot

[Michael Heerdegen]

Andreas Schwab <schwab@suse.de> writes:

> On Mär 26 2019, Michael Heerdegen <michael_heerdegen@web.de> wrote:
>
> > But if you destructively modify the result of the backquote expression,
> > you may also change Y destructively (but not X).  Things like these
> > might be clear if you come from Common Lisp, but it's all not obvious
> > IMHO.
>
> You need always be careful when destructively modifying structures,
> independent of how they were computed.

What I wanted to say was that it can be surprising that splicing may
reuse conses at all (it had been to me).  The manual only tells that the
elements of the spliced list "become elements of the result".  I had to
learn it the hard way.  I had been careful, but I just didn't expect a
problem in that situation.

Michael.

bug#34975: 26.1.92; In backquote, the comma marker does not work with variable name started with dot

[Noam Postavsky]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Drew Adams <drew.adams@oracle.com> writes:
>
>> > I dunno or have forgotten for what it had been intended, there are no
>> > real uses in the Emacs Elisp sources.
>> >

>> (I don't in fact use it, apparently, but I thought I
>> might have, and if I did use it instead of ,@ then it
>> would no doubt be for that reason.)
>>
>> On the other hand, Common Lisp says that ,. has this
>> difference in meaning from ,@:
>>
>> "Anywhere ``,@'' may be used, the syntax ``,.'' may
>> be used instead to indicate that it is permissible
>> to destroy the list produced by the form following
>> the ``,.''; this may permit more efficient code,
>> using nconc instead of append, for example."
>
> Yes, thanks.  I also found that post:
>
> https://lists.gnu.org/archive/html/emacs-devel/2012-02/msg00330.html
>
> The state is the same as back then: ,. is a reader macro in Emacs Lisp,
> but the head of the expansion (the symbol named ",.") doesn't have any
> semantics, even not in backquote.

There's also Bug#19790 about this.  I think it makes sense to just
remove this reader macro, as far as I can tell, nobody really wants this
destructive splicing feature.

bug#34975: 26.1.92; In backquote, the comma marker does not work with variable name started with dot

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Date: Wed, 03 Apr 2019 23:31:24 -0400
> Cc: Xu Chunyang <mail@xuchunyang.me>, 34975@debbugs.gnu.org
> 
> There's also Bug#19790 about this.  I think it makes sense to just
> remove this reader macro, as far as I can tell, nobody really wants this
> destructive splicing feature.

How hard would it be fixing it?  I'm uneasy with removing features
because we are confused about them.

bug#34975: 26.1.92; In backquote, the comma marker does not work with variable name started with dot

[Noam Postavsky]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Noam Postavsky <npostavs@gmail.com>
>> Date: Wed, 03 Apr 2019 23:31:24 -0400
>> Cc: Xu Chunyang <mail@xuchunyang.me>, 34975@debbugs.gnu.org
>> 
>> There's also Bug#19790 about this.  I think it makes sense to just
>> remove this reader macro, as far as I can tell, nobody really wants this
>> destructive splicing feature.
>
> How hard would it be fixing it?  I'm uneasy with removing features
> because we are confused about them.

The destructive splicing feature was never added though.  Only the
reader macro part.  But if you're asking about possible breakage, then
yes, it's possible that someone out there wrote a macro which gives some
semantics to ",.", like pcase gives its own semantics to "`" and ",".

bug#34975: 26.1.92; In backquote, the comma marker does not work with variable name started with dot

[Basil L. Contovounesios]

Noam Postavsky <npostavs@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Noam Postavsky <npostavs@gmail.com>
>>> Date: Wed, 03 Apr 2019 23:31:24 -0400
>>> Cc: Xu Chunyang <mail@xuchunyang.me>, 34975@debbugs.gnu.org
>>> 
>>> There's also Bug#19790 about this.  I think it makes sense to just
>>> remove this reader macro, as far as I can tell, nobody really wants this
>>> destructive splicing feature.
>>
>> How hard would it be fixing it?  I'm uneasy with removing features
>> because we are confused about them.
>
> The destructive splicing feature was never added though.  Only the
> reader macro part.  But if you're asking about possible breakage, then
> yes, it's possible that someone out there wrote a macro which gives some
> semantics to ",.", like pcase gives its own semantics to "`" and ",".

I, for one, have several times found myself using nconc+list where I
would rather use backquote, precisely because the latter is never
destructive.

Not a must-have by any measure, but definitely a nice-to-have,
especially given the reader macro already exists.

-- 
Basil

bug#34975: 26.1.92; In backquote, the comma marker does not work with variable name started with dot

[Noam Postavsky]

>>>> as far as I can tell, nobody really wants this
>>>> destructive splicing feature.

> I, for one, have several times found myself using nconc+list where I
> would rather use backquote, precisely because the latter is never
> destructive.

Okay, I stand corrected.  But to be honest, that sounds like premature
optimization to me.  By the way, in Bug#19790 Stefan opposed making ",."
destructive.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19790#23

bug#34975: 26.1.92; In backquote, the comma marker does not work with variable name started with dot

[Basil L. Contovounesios]

Noam Postavsky <npostavs@gmail.com> writes:

>>>>> as far as I can tell, nobody really wants this
>>>>> destructive splicing feature.
>
>> I, for one, have several times found myself using nconc+list where I
>> would rather use backquote, precisely because the latter is never
>> destructive.
>
> Okay, I stand corrected.  But to be honest, that sounds like premature
> optimization to me.

That or dubious style, indeed. ;)

> By the way, in Bug#19790 Stefan opposed making ",."  destructive.
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19790#23

My knee-jerk reaction is simply "if it's already there, why not realise
its purpose", but I ultimately don't mind either way.

-- 
Basil

bug#34975: 26.1.92; In backquote, the comma marker does not work with variable name started with dot

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Cc: michael_heerdegen@web.de,  Eli Zaretskii <eliz@gnu.org>,  mail@xuchunyang.me,  34975@debbugs.gnu.org
> Date: Fri, 05 Apr 2019 02:15:18 +0100
> 
> My knee-jerk reaction is simply "if it's already there, why not realise
> its purpose", but I ultimately don't mind either way.

Same here.