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.

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.

[Howard McCay]

[-- Attachment #1: Type: text/plain, Size: 4250 bytes --]

This is not a bug report.


This is a request for consideration of an improvement to elisp.

I wish to differ with an opinion expressed in section
"2.3.6.2 Dotted Pair Notation" of the elisp manual which reads:

"The syntax (rose . violet . buttercup) is invalid
because there is nothing that it could mean."

This syntax could mean:
(rose . violet . buttercup)
=
(rose . (violet . buttercup))
=
(rose (violet . buttercup))

Similarly
(rose . violet . buttercup . periwinkle)
=
(rose . (violet . buttercup . periwinkle))
=
(rose . (violet . (buttercup . periwinkle)))
=
(rose violet (buttercup . periwinkle))

These are lists ending with their final two elements
inside their final cons pair
instead of terminating with a cons pair
with their very final element for its CAR and nil for its CDR.

This interpretation can only be allowed
if you can allow your lisp interpreter/condenser to do so.

So this is not merely a difference of opinion as to what
(rose . violet . buttercup)
should mean.

It is a request for modification/expansion/liberalization
of the lisp interpreter/condenser to be able to allow and interpret
(rose . violet . buttercup)
as requested above.

Lists so ending are already allowed in elisp
if the programmer includes explicitly
the requested-to-be-assumed parentheses.

I do not know if these double-element-in-their-final-cons lists
are treated the same as nil-in-the-CDR-of-final-cons lists.

I believe these two types of list should be handled identically
by all functions called to process these lists.

When concatenating lists whose non-final list(s) of the concatenation
terminate with a double-element cons,
that double-element cons should be expanded into two conses:
one having the original penultimate element for its CAR
and a new next cons for its CDR,
this new next cons having the original final element for its CAR
and the first element of the next list of the concatenation for its CDR.

The final list of a concatenation should not be changed.

When adding a single element to the end of a double-element-terminated list,
the double element should be expanded into two conses:
one having the original penultimate element for its CAR
and a new next and final double-element cons for its CDR,
this new next and final cons having the original final element for its CAR
and the new added final element for its CDR.

When deleting the final element from a double-element-terminated list,
replacing the final element with nil may be easier and more efficient
than deleting (freeing memory of) the final cons
and moving the penultimate element into the CDR of the penultimate cons,
however, the second method preserves the double-element-terminated list.

The same method should be used to split a double-element-terminated list
or to delete multiple elements from the end
of a double-element-terminated list.
One moves the CAR from the final cons before the split or deletion
into the penultimate cons before the split or deletion, replacing its CDR.
The memory of the original final cons before the split or deletion
should be freed along with the memory of any deleted portion.

Other list operations
(such as removing or deleting initial or internal portions of a list)
should be able to operate identically
on these two differently terminated lists.

Only operations involving the final element
of a double-element-terminated list
(such as sorting the elements of a double-element-terminated list)
will need to handle the final element in the CDR of the final cons
with special attention.

I do not know if it is elip's philosophy that
deleting all but one element from a list
or extracting a list segment containing but a single element
should produce a list containing but one element
(a cons with that element for its CAR and nil for its CDR)
or should produce just that single element.
Or whether a cons with nil for its CDR
should be considered the same
as a single element equal to the CAR of that cons.

It is my hope that all list-handling functions
call a very limited number of list-handling primitives
to manipulate their lists,
so that these changes will be simple to make.

Thank you for reading this request.
I would greatly appreciate receiving an email
with your thoughts on this request.

   

[-- Attachment #2: Type: text/html, Size: 13284 bytes --]

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.

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 805 bytes --]


() Howard McCay <howardmccay@yahoo.com>
() Wed, 5 Oct 2016 07:15:05 +0000 (UTC)

   (rose . (violet . buttercup))
   =
   (rose (violet . buttercup))

For Lisp (and Scheme), this relation does not hold.  To see for
yourself, in the *scratch* buffer, add:

 '(rose . (violet . buttercup))

and type ‘C-j’ (NB: single-quote at the beginning of the form).
You should see:

 (rose violet . buttercup)

Any change you propose to ‘read’ that assumes (or prescribes)
otherwise will be DOA.

-- 
Thien-Thi Nguyen -----------------------------------------------
 (defun responsep (type via)
   (case type
     (technical (eq 'mailing-list via))
     ...))                              748E A0E8 1CB8 A748 9BFA
--------------------------------------- 6CE4 6703 2224 4C80 7502


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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.

[Howard McCay]

[-- Attachment #1: Type: text/plain, Size: 1959 bytes --]

Dear Mr. Nguyen:
Thank you for your timely response to my request.
You are correct.  It was my mistake to have included the extra erroneous parenthesis.
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.
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.
      From: Thien-Thi Nguyen <ttn@gnu.org>
 To: Howard McCay <howardmccay@yahoo.com> 
Cc: 24621@debbugs.gnu.org
 Sent: Wednesday, October 5, 2016 4:08 AM
 Subject: Re: 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.
   

() Howard McCay <howardmccay@yahoo.com>
() Wed, 5 Oct 2016 07:15:05 +0000 (UTC)

  (rose . (violet . buttercup))
  =
  (rose (violet . buttercup))

For Lisp (and Scheme), this relation does not hold.  To see for
yourself, in the *scratch* buffer, add:

 '(rose . (violet . buttercup))

and type ‘C-j’ (NB: single-quote at the beginning of the form).
You should see:

 (rose violet . buttercup)

Any change you propose to ‘read’ that assumes (or prescribes)
otherwise will be DOA.

-- 
Thien-Thi Nguyen -----------------------------------------------
 (defun responsep (type via)
  (case type
    (technical (eq 'mailing-list via))
    ...))                              748E A0E8 1CB8 A748 9BFA
--------------------------------------- 6CE4 6703 2224 4C80 7502


   

[-- Attachment #2: Type: text/html, Size: 4504 bytes --]

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