[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#24621: 24.5.1 (i686-pc-mingw32) of 2015-04-11 on LEG570; elisp manua
From: |
Stefan Kangas |
Subject: |
bug#24621: 24.5.1 (i686-pc-mingw32) of 2015-04-11 on LEG570; elisp manual; third attempt; please forgive and disregard first and second. |
Date: |
Fri, 08 Nov 2019 04:20:14 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
tags 24621 + wontfix
close 24621
thanks
Howard McCay <howardmccay@yahoo.com> writes:
> Please revise my request to allow
> (rose . violet . buttercup) to be interpreted as
> (rose . (violet . buttercup)) which, as you have explained, is the same as
> (rose violet . buttercup)
>
> I understand this alternative to be a cons whose CAR is rose and
> whose CDR points to a cons whose CAR is violet and whose CDR is
> buttercup. You have explained that this is equivalent to a two
> member list whose first member is rose and whose second member is a
> cons whose CAR is violet and whose CDR is buttercup.
I think you have misunderstood something fundamental regarding how
lists work in Lisp. The suggestion is to allow:
'(1 . 2 . 3)
As a synonym for:
'(1 2 . 3)
This suggestion makes little sense to me. Note first that these two
forms are equivalent in Emacs Lisp:
'(1 . 2)
(cons 1 2)
But it is not clear how to translate:
(1 . 2 . 3)
into the equivalent cons-form. cons takes two arguments by
definition.
Using cons is actually how you construct a Lisp list:
'(1 . (2 . nil))
...is equivalent to:
(list 1 2)
This is just how Lisp works, and has always worked.
> My expanded request is that all functions expecting a list for an
> argument should treat these alternative lists just as they would
> treat a nil-terminated list.
This proposal makes even less sense to me. It implies that this:
'(1 . 2)
Should be equivalent to this:
'(1 2)
But the second nil-terminated list actually has a different value.
This is easily demonstrated by evaluating these expressions:
(cdr '(1 2))
(cdr '(1 . 2))
The suggestions above would mean to change a fundamental abstraction
of Lisp (lists). I don't think this is something that we want to do.
I'm therefore closing this as wontfix.
Best regards,
Stefan Kangas
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#24621: 24.5.1 (i686-pc-mingw32) of 2015-04-11 on LEG570; elisp manual; third attempt; please forgive and disregard first and second.,
Stefan Kangas <=