* 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. [not found] ` <1464462670.2852406.1475651578683@mail.yahoo.com> @ 2016-10-05 7:15 ` Howard McCay 2016-10-05 11:08 ` Thien-Thi Nguyen 0 siblings, 1 reply; 4+ messages in thread From: Howard McCay @ 2016-10-05 7:15 UTC (permalink / raw) To: 24621 [-- 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 --] ^ permalink raw reply [flat|nested] 4+ messages 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. 2016-10-05 7:15 ` 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 @ 2016-10-05 11:08 ` Thien-Thi Nguyen 2016-10-09 23:22 ` Howard McCay 0 siblings, 1 reply; 4+ messages in thread From: Thien-Thi Nguyen @ 2016-10-05 11:08 UTC (permalink / raw) To: Howard McCay; +Cc: 24621 [-- 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 --] ^ permalink raw reply [flat|nested] 4+ messages 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. 2016-10-05 11:08 ` Thien-Thi Nguyen @ 2016-10-09 23:22 ` Howard McCay 2019-11-08 3:20 ` Stefan Kangas 0 siblings, 1 reply; 4+ messages in thread From: Howard McCay @ 2016-10-09 23:22 UTC (permalink / raw) To: 24621@debbugs.gnu.org [-- 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 --] ^ permalink raw reply [flat|nested] 4+ messages 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. 2016-10-09 23:22 ` Howard McCay @ 2019-11-08 3:20 ` Stefan Kangas 0 siblings, 0 replies; 4+ messages in thread From: Stefan Kangas @ 2019-11-08 3:20 UTC (permalink / raw) To: Howard McCay; +Cc: 24621@debbugs.gnu.org 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-11-08 3:20 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <1882419341.2371236.1475649537138.ref@mail.yahoo.com> [not found] ` <1882419341.2371236.1475649537138@mail.yahoo.com> [not found] ` <417241573.1229709.1475649965531@mail.yahoo.com> [not found] ` <1464462670.2852406.1475651578683@mail.yahoo.com> 2016-10-05 7:15 ` 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 2016-10-05 11:08 ` Thien-Thi Nguyen 2016-10-09 23:22 ` Howard McCay 2019-11-08 3:20 ` Stefan Kangas
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.