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]

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