From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Howard McCay Newsgroups: gmane.emacs.bugs 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: Wed, 5 Oct 2016 07:15:05 +0000 (UTC) Message-ID: <1818766431.2865153.1475651705954@mail.yahoo.com> References: <1882419341.2371236.1475649537138.ref@mail.yahoo.com> <1882419341.2371236.1475649537138@mail.yahoo.com> <417241573.1229709.1475649965531@mail.yahoo.com> <1464462670.2852406.1475651578683@mail.yahoo.com> Reply-To: Howard McCay NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2865152_2147220805.1475651705950" X-Trace: blaine.gmane.org 1475653938 391 195.159.176.226 (5 Oct 2016 07:52:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 5 Oct 2016 07:52:18 +0000 (UTC) To: 24621@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 05 09:52:13 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1brgzf-00065d-Fc for geb-bug-gnu-emacs@m.gmane.org; Wed, 05 Oct 2016 09:51:59 +0200 Original-Received: from localhost ([::1]:47024 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1brgze-0002ZB-2B for geb-bug-gnu-emacs@m.gmane.org; Wed, 05 Oct 2016 03:51:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51829) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1brgxq-0001GU-HQ for bug-gnu-emacs@gnu.org; Wed, 05 Oct 2016 03:50:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1brgxm-000589-9r for bug-gnu-emacs@gnu.org; Wed, 05 Oct 2016 03:50:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:38986) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1brgxl-000581-Um for bug-gnu-emacs@gnu.org; Wed, 05 Oct 2016 03:50:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1brgxl-00063z-Ny for bug-gnu-emacs@gnu.org; Wed, 05 Oct 2016 03:50:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Howard McCay Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 05 Oct 2016 07:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 24621 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: "bug-gnu-emacs@gnu.org" Original-Received: via spool by submit@debbugs.gnu.org id=B.147565380023295 (code B ref -1); Wed, 05 Oct 2016 07:50:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 5 Oct 2016 07:50:00 +0000 Original-Received: from localhost ([127.0.0.1]:45176 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1brgxk-00063e-8X for submit@debbugs.gnu.org; Wed, 05 Oct 2016 03:50:00 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54882) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1brgT0-0005BZ-3B for submit@debbugs.gnu.org; Wed, 05 Oct 2016 03:18:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1brgSt-0004dZ-34 for submit@debbugs.gnu.org; Wed, 05 Oct 2016 03:18:08 -0400 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:57962) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1brgSs-0004dR-VW for submit@debbugs.gnu.org; Wed, 05 Oct 2016 03:18:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45845) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1brgSq-0008Hu-2s for bug-gnu-emacs@gnu.org; Wed, 05 Oct 2016 03:18:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1brgSl-0004bt-4Q for bug-gnu-emacs@gnu.org; Wed, 05 Oct 2016 03:18:03 -0400 Original-Received: from nm43-vm4.bullet.mail.gq1.yahoo.com ([67.195.87.219]:44949) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1brgSk-0004bZ-PQ for bug-gnu-emacs@gnu.org; Wed, 05 Oct 2016 03:17:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1475651878; bh=XhaAlC89HNa0B4atglOz6AWyvwytFUPlNB7yajivCSE=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=etXdmgZlcLI56BkUvaJXXE1GosqAfYQDZjOLAEIBypAOdhydgJ51Akj/hlUxGzmlSsiF+PXdek6z1aX4KCId0sKUJMKdYJxNUZhhXsFyPbaQYEkW2f2Z2rffAnRfJ0d018tDAhg8+nq7Q4y0SrcAmyXYI36fem2kK+EmfoLP0WFDVG3ZNv7Gm2fLuzo13ZiK08gxNG9/u+cU665Ra47tl5Lf0/uFlPj4aJf2uO52zyZ2HoKaFIaY9jOeK3WMSOEVgAUkT7iQ8uXMrmu8xWAa99B7FQlmxR8dBzngMwLd/JyygbsbYJoH3NEVkXsW1+L764LGhLLj1cBs7GCebgC/LQ== Original-Received: from [127.0.0.1] by nm43.bullet.mail.gq1.yahoo.com with NNFMP; 05 Oct 2016 07:17:58 -0000 Original-Received: from [98.137.12.191] by nm43.bullet.mail.gq1.yahoo.com with NNFMP; 05 Oct 2016 07:15:13 -0000 Original-Received: from [98.137.12.211] by tm12.bullet.mail.gq1.yahoo.com with NNFMP; 05 Oct 2016 07:15:13 -0000 Original-Received: from [127.0.0.1] by omp1019.mail.gq1.yahoo.com with NNFMP; 05 Oct 2016 07:15:13 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 540426.25889.bm@omp1019.mail.gq1.yahoo.com X-YMail-OSG: 4NyFosgVM1ltZLcHjM8j1F5TsPNeUQ.SAWkiPNTyTz9SFpnKObuidAwDMllH50o GaGdHkiTqQoh3u6BHrrLf0T0syeyr3Whv8LIs6QF4UHEDSGWh6g17As5iaSkIXpbG8Fni09ljcg6 Gmf50Ic35Ko5vzTYafSxxpbk2x8r1ujVWtK1nFSCML2w81T2YCnj2RnBu2wWgcWoRlznjadGwvG. sLf4ZiPNpriwNgFImfNZAb7xlG5mKy89_dvY9d0Bnt1I_t1jV2YEp7uDps5kefVxEEZVxw.GTrdi 3v3wWbKZ5tWHuQoiUV1co0nMGcZgLM2rgp56nB3EmZ1TipdLQ9qvA8vygsCLhCXh_g5dGQd8rVqm tLw9a6rBun10Mhw7HbwFeY9FuJmIyvn0XDi2YxjK6QBCpaktBWYIDE2Co1Qh7Gp8SX50t9TwWJry 0LqYzGmKQRzj8m.LG4FopPLPuUafckh7Fli_3Aa.kq6V7cxFqn4PEYx9GhZp0c3pmLo.K9CrRThw kP4KcgGZARvWZvHfZ4uZ7AKfvjCQewH7EhBeoTN7oNp6gWhmY1rWd8CUWLTh0hB62sdrlGj9qp7N Z_DwK Original-Received: from jws300042.mail.gq1.yahoo.com by sendmailws129.mail.gq1.yahoo.com; Wed, 05 Oct 2016 07:15:13 +0000; 1475651713.154 In-Reply-To: <1464462670.2852406.1475651578683@mail.yahoo.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Mailman-Approved-At: Wed, 05 Oct 2016 03:50:00 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:124088 Archived-At: ------=_Part_2865152_2147220805.1475651705950 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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. ------=_Part_2865152_2147220805.1475651705950 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is not a bug report.


<= div class=3D"yahoo_quoted" id=3D"yui_3_16_0_ym19_1_1475649112593_16459" sty= le=3D"display: block;">
This is a request = for consideration of an improvement to elisp.

I wish to differ with an o= pinion expressed in section
"2.3.6.2 Dotted Pair Notation" of the elisp ma= nual which reads:

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

This syntax could mean:
(ro= se . violet . buttercup)
=3D
(rose . (violet . buttercup))
=3D
(rose (v= iolet . buttercup))

Similarly
(rose . violet . buttercup . periwinkle)<= br id=3D"yiv5498238883yui_3_16_0_ym19_1_1475649112593_13852" clear=3D"none"= >=3D
(rose . (violet . buttercup . periwinkle))
=3D
(rose . (violet . (b= uttercup . periwinkle)))
=3D
(rose violet (buttercup . periwinkle))

Th= ese are lists ending with their final two elements
inside their final cons= pair
instead of terminating with a cons pair
with their very final eleme= nt for its CAR and nil for its CDR.

This interpretation can only be allo= wed
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 . buttercu= p)
should mean.

It is a request for modification/expansion/liberalizati= on
of the lisp interpreter/condenser to be able to allow and interpret
(r= ose . violet . buttercup)
as requested above.

Lists so ending are alrea= dy allowed in elisp
if the programmer includes explicitly
the requested-t= o-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 lis= ts.

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

When concatenating lists wh= ose 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 f= or its CDR,
this new next cons having the original final element for its C= AR
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 addin= g a single element to the end of a double-element-terminated list,
the dou= ble element should be expanded into two conses:
one having the original pe= nultimate 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 eleme= nt for its CAR
and the new added final element for its CDR.

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

The same method should be used to split a d= ouble-element-terminated list
or to delete multiple elements from the end<= br id=3D"yiv5498238883yui_3_16_0_ym19_1_1475649112593_13911" clear=3D"none"= >of a double-element-terminated list.
One moves the CAR from the final con= s before the split or deletion
into the penultimate cons before the split = or deletion, replacing its CDR.
The memory of the original final cons befo= re the split or deletion
should be freed along with the memory of any dele= ted portion.

Other list operations
(such as removing or deleting initia= l or internal portions of a list)
should be able to operate identicallyo= n these two differently terminated lists.

Only operations involving the = final element
of a double-element-terminated list
(such as sorting the el= ements 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 k= now if it is elip's philosophy that
deleting all but one element from a li= st
or extracting a list segment containing but a single element
should pr= oduce 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 w= hether a cons with nil for its CDR
should be considered the same
as a sin= gle element equal to the CAR of that cons.


It is my hope that all list-han= dling 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 a= n email
with your thoughts on this request.

------=_Part_2865152_2147220805.1475651705950--