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.