From unknown Sun Sep 07 16:50:07 2025 X-Loop: help-debbugs@gnu.org 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. 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: To: 24621@debbugs.gnu.org X-Debbugs-Original-To: "bug-gnu-emacs@gnu.org" Reply-To: Howard McCay Received: via spool by submit@debbugs.gnu.org id=B.147565380023295 (code B ref -1); Wed, 05 Oct 2016 07:50:01 +0000 Received: (at submit) by debbugs.gnu.org; 5 Oct 2016 07:50:00 +0000 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 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 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 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: *** X-Spam-Status: No, score=3.4 required=5.0 tests=BAYES_50,FORGED_YAHOO_RCVD, FREEMAIL_FROM,HK_RANDOM_ENVFROM,HK_RANDOM_FROM,HTML_MESSAGE,T_DKIM_INVALID autolearn=disabled version=3.3.2 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 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 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 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== Received: from [127.0.0.1] by nm43.bullet.mail.gq1.yahoo.com with NNFMP; 05 Oct 2016 07:17:58 -0000 Received: from [98.137.12.191] by nm43.bullet.mail.gq1.yahoo.com with NNFMP; 05 Oct 2016 07:15:13 -0000 Received: from [98.137.12.211] by tm12.bullet.mail.gq1.yahoo.com with NNFMP; 05 Oct 2016 07:15:13 -0000 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 Received: from jws300042.mail.gq1.yahoo.com by sendmailws129.mail.gq1.yahoo.com; Wed, 05 Oct 2016 07:15:13 +0000; 1475651713.154 Date: Wed, 5 Oct 2016 07:15:05 +0000 (UTC) From: Howard McCay Message-ID: <1818766431.2865153.1475651705954@mail.yahoo.com> In-Reply-To: <1464462670.2852406.1475651578683@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> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2865152_2147220805.1475651705950" Content-Length: 18687 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-Received-From: 2001:4830:134:3::11 X-Spam-Score: -1.7 (-) 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 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) ------=_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-- From unknown Sun Sep 07 16:50:07 2025 X-Loop: help-debbugs@gnu.org 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. Resent-From: Thien-Thi Nguyen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 05 Oct 2016 11:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24621 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Howard McCay Cc: 24621@debbugs.gnu.org Reply-To: 24621@debbugs.gnu.org Received: via spool by 24621-submit@debbugs.gnu.org id=B24621.147566804125683 (code B ref 24621); Wed, 05 Oct 2016 11:48:02 +0000 Received: (at 24621) by debbugs.gnu.org; 5 Oct 2016 11:47:21 +0000 Received: from localhost ([127.0.0.1]:45225 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1brkfR-0006gA-23 for submit@debbugs.gnu.org; Wed, 05 Oct 2016 07:47:21 -0400 Received: from mail.agora-net.com ([67.59.132.6]:54965) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1brkfP-0006g1-DY for 24621@debbugs.gnu.org; Wed, 05 Oct 2016 07:47:19 -0400 Received: from ttn by mail.agora-net.com with local (Exim 4.82) (envelope-from ) id 1brkfO-0000bg-JN; Wed, 05 Oct 2016 07:47:18 -0400 Received: from ttn by zigzag.favinet with local (Exim 4.80) (envelope-from ) id 1brk3k-0006Ks-5W; Wed, 05 Oct 2016 13:08:24 +0200 From: Thien-Thi Nguyen In-Reply-To: <1818766431.2865153.1475651705954@mail.yahoo.com> (Howard McCay's message of "Wed, 5 Oct 2016 07:15:05 +0000 (UTC)") 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> <1818766431.2865153.1475651705954@mail.yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) Mail-Followup-To: 24621@debbugs.gnu.org Date: Wed, 05 Oct 2016 13:08:13 +0200 Message-ID: <87int76oki.fsf@zigzag.favinet> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ttn@gnuvola.org X-SA-Exim-Scanned: No (on mail.agora-net.com); SAEximRunCond expanded to false X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) --==-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable () Howard McCay () Wed, 5 Oct 2016 07:15:05 +0000 (UTC) (rose . (violet . buttercup)) =3D (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 =E2=80=98C-j=E2=80=99 (NB: single-quote at the beginning of the fo= rm). You should see: (rose violet . buttercup) Any change you propose to =E2=80=98read=E2=80=99 that assumes (or prescribe= s) otherwise will be DOA. =2D-=20 Thien-Thi Nguyen ----------------------------------------------- (defun responsep (type via) (case type (technical (eq 'mailing-list via)) ...)) 748E A0E8 1CB8 A748 9BFA =2D-------------------------------------- 6CE4 6703 2224 4C80 7502 --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlf03yAACgkQZwMiJEyAdQIcvQCfZe4p50bZfLSAkwJ8dPqZOCIV J90An3qaCGxdgx2Zy4oKfeUFjq4z+kT0 =A3Eo -----END PGP SIGNATURE----- --==-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 05 08:17:18 2016 Received: (at control) by debbugs.gnu.org; 5 Oct 2016 12:17:18 +0000 Received: from localhost ([127.0.0.1]:45256 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1brl8Q-0007ak-IO for submit@debbugs.gnu.org; Wed, 05 Oct 2016 08:17:18 -0400 Received: from mail-it0-f43.google.com ([209.85.214.43]:35062) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1brl8P-0007aT-21 for control@debbugs.gnu.org; Wed, 05 Oct 2016 08:17:17 -0400 Received: by mail-it0-f43.google.com with SMTP id r192so182853495ita.0 for ; Wed, 05 Oct 2016 05:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:subject:date:message-id:mime-version; bh=YTOB/cCTnI7skDESujLfIee3Jeu4qFjEPeLAVqCM4LA=; b=EAc3HLsAAk62ThMPnlpsgYDHO2ZNuPxHRgRSiuckRXnfBWqApZug9NXgBiy7WJdMjH npie35aJwBX2TTBqXkrkYlTOI7qUUCMxLjsqdtgF8uVduUIIseC+EKMuHr9BqbgWVOzL RRJej5a99a291wRquVfPGB/hdRz6k0Rx1QEOyq+Wl3FQLwjjRkhHCpTdQ6nnWMTZwIMG 0UgTYBH3WqmAED06mlHyZSYxvJhUWgYc4L2D944f3buxHfPOJaN01wJGpFKiNzjk40O3 yOZ8ynN4h6iocePchw9bKlqCchfGxfbaSIclsecLeSnwc+2CjOJ9SUHB7qXcl4bPhklg PZRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:subject:date:message-id :mime-version; bh=YTOB/cCTnI7skDESujLfIee3Jeu4qFjEPeLAVqCM4LA=; b=Dr6GE3qTi+lQSBMdGJo7Bl3/5U2parhwXOdF7W1c7ni5Hj3uMtH6PmDkqWsXH1Fppa coRFMHpGhsC1ZzItSqz/SRXVIk228S0i0MhQHR+3jH+yWL3VKYWpXFXOBoGuhGjY99BR WSySA7BIXF0yG2b7XnEbwAXhsamWTQOZ9jSh78/+ESw1UplUch/4hq79SRE95rALMl4b dxY+Iku7vCgyCAK356PgI9AXzM1fRqkxH6FcK6bTi7LlXCmKpAnghUZyblKcOHzgkp+S ilklEoYZuhd/nJweza4ooxvW+qmu2bfsNK2flFB7msYr7zMIab5npo0Fhgo9nb0+g69u yDJQ== X-Gm-Message-State: AA6/9RlYscj4tMIHbS2LIMvHUceOpxGT/d8I6gAXznnHhUDjhENI5vK2tYnUrgzqUZjAiA== X-Received: by 10.107.14.78 with SMTP id 75mr9631034ioo.79.1475669821377; Wed, 05 Oct 2016 05:17:01 -0700 (PDT) Received: from zony ([45.2.7.130]) by smtp.googlemail.com with ESMTPSA id a192sm11549032itc.8.2016.10.05.05.17.00 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 05 Oct 2016 05:17:00 -0700 (PDT) From: npostavs@users.sourceforge.net To: control@debbugs.gnu.org Subject: control message for bug #24621 Date: Wed, 05 Oct 2016 08:17:33 -0400 Message-ID: <871szvxa5e.fsf@users.sourceforge.net> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) severity 24621 wishlist quit From unknown Sun Sep 07 16:50:07 2025 X-Loop: help-debbugs@gnu.org 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. Resent-From: Howard McCay Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 09 Oct 2016 23:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24621 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "24621@debbugs.gnu.org" <24621@debbugs.gnu.org> Reply-To: Howard McCay Received: via spool by 24621-submit@debbugs.gnu.org id=B24621.14760553965755 (code B ref 24621); Sun, 09 Oct 2016 23:24:02 +0000 Received: (at 24621) by debbugs.gnu.org; 9 Oct 2016 23:23:16 +0000 Received: from localhost ([127.0.0.1]:50316 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btNR5-0001Uk-S6 for submit@debbugs.gnu.org; Sun, 09 Oct 2016 19:23:16 -0400 Received: from nm21-vm4.bullet.mail.gq1.yahoo.com ([98.136.217.51]:39189) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1btNR3-0001UU-P1 for 24621@debbugs.gnu.org; Sun, 09 Oct 2016 19:23:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1476055387; bh=de4S5PCvQe41PuTN2lyXwi6wU44pwFyKE2J4TyfCL/8=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=SKMXCTDlxkfYlyJcR6xcDW57+uUo5bXH5dI4cDwhKSBk+05OJlwdNqMK+bzypEQ0Q8SOgood3vgfh0Sxq94U2pdmdd2KKa1pUeI+o/LMJW1aBfcGcfnO+zYXcTDeUUiK0Zn7zRDOWcVd8eBn9X4DSM1QzKh54oYQX5sVPGverKvdElJQfHljGzGJfY/pxfVTT7KLOjFFjJ+8mRYv+0PAikaM0cva4+nfhZNGg79GvkYVrNHvLfYxGWJoZP16rka/MSQnhvefqorIZPMgDopdl7Bo95hvTBSh8qphWcTLuWG4JL9g/n9oRxD1L1yz+Ad0ZjNmzz6GD4ELIi1usITPNA== Received: from [216.39.60.184] by nm21.bullet.mail.gq1.yahoo.com with NNFMP; 09 Oct 2016 23:23:07 -0000 Received: from [98.137.12.215] by tm20.bullet.mail.gq1.yahoo.com with NNFMP; 09 Oct 2016 23:23:07 -0000 Received: from [127.0.0.1] by omp1023.mail.gq1.yahoo.com with NNFMP; 09 Oct 2016 23:23:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 634917.3960.bm@omp1023.mail.gq1.yahoo.com X-YMail-OSG: uiK13rgVM1kiukL9dtPwgrww8eu.HcSbdNjKwBLSxFl20bujpBkkUpHmPzo_M7b mP3hg9d1GWLIxVl4u_jdloPOcg9N6xt0L6hXuhwyMqmvsVKdQrcTpO5E8Wfd1cHdKngqAb1NPJNR qJVGmcdvn.0mMfk5AcVwKcwciCGnFxRfX9RW1JPb66tFmmASN.2oKccQJDzm3ehDT0IiM80uhFq0 WpOhdKSX5nbfghQqjj71JXhJhHlpu31H.oxVT7PHr.rHb.x1E7WkWK9Fa33G3v5rQX55J_OgkCHh sDr2YO4Mne7ZOqNG4cLuHXDFE54ayVZ4NkCIFX4rwuOvO1jZ.gJQXGufBQd0T_WIcS6gRSXoZfMF 9cShgBTF.LrzM7CPtEONDb9gjgBCWsxW.lUHt.KHv2l2scUXS0nirFRHmkvTibdAdyAYqujAlo6t mGPoeWFjtMAJsZCl6JKRK_MZlfd7UaCIffpPjPPT_wUxTMfdwaHJBmSJzhS7WnrhUIAKLGpmBbNf kH9nfjb77lP5QpzUOCD6s.lZueC0wJwhpRz.rzGzz3cEMS_XMRPliSSTAI.6Zcj9fT9s- Received: from jws300054.mail.gq1.yahoo.com by sendmailws125.mail.gq1.yahoo.com; Sun, 09 Oct 2016 23:23:07 +0000; 1476055387.055 Date: Sun, 9 Oct 2016 23:22:23 +0000 (UTC) From: Howard McCay Message-ID: <464741169.1690694.1476055344006@mail.yahoo.com> In-Reply-To: <87int76oki.fsf@zigzag.favinet> 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> <1818766431.2865153.1475651705954@mail.yahoo.com> <87int76oki.fsf@zigzag.favinet> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1690693_862103298.1476055344001" Content-Length: 7197 X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) ------=_Part_1690693_862103298.1476055344001 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Mr. Nguyen: Thank you for your timely response to my request. You are correct.=C2=A0 It was my mistake to have included the extra erroneo= us parenthesis. Please revise my request to allow(rose . violet . buttercup) to be interpre= ted as(rose . (violet . buttercup)) which, as you have explained, is the sa= me 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.=C2=A0 You = have explained that this is equivalent to a two member list whose first mem= ber 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-termina= ted list. From: Thien-Thi Nguyen To: Howard McCay =20 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. =20 () Howard McCay () Wed, 5 Oct 2016 07:15:05 +0000 (UTC) =C2=A0 (rose . (violet . buttercup)) =C2=A0 =3D =C2=A0 (rose (violet . buttercup)) For Lisp (and Scheme), this relation does not hold.=C2=A0 To see for yourself, in the *scratch* buffer, add: '(rose . (violet . buttercup)) and type =E2=80=98C-j=E2=80=99 (NB: single-quote at the beginning of the fo= rm). You should see: (rose violet . buttercup) Any change you propose to =E2=80=98read=E2=80=99 that assumes (or prescribe= s) otherwise will be DOA. --=20 Thien-Thi Nguyen ----------------------------------------------- (defun responsep (type via) =C2=A0 (case type =C2=A0 =C2=A0 (technical (eq 'mailing-list via)) =C2=A0 =C2=A0 ...))=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 748E A0E8 1CB8 A748 9BFA --------------------------------------- 6CE4 6703 2224 4C80 7502 =20 ------=_Part_1690693_862103298.1476055344001 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 sam= e as
(rose vi= olet . buttercup)

I u= nderstand this alternative to be a cons whose CAR is rose and whose CDR poi= nts to a cons whose CAR is violet and whose CDR is buttercup.  You hav= e 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 CD= R is buttercup.

My ex= panded request is that all functions expecting a list for an argument shoul= d treat these alternative lists just as they would treat a nil-terminated l= ist.
------=_Part_1690693_862103298.1476055344001-- From unknown Sun Sep 07 16:50:07 2025 X-Loop: help-debbugs@gnu.org 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. Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Nov 2019 03:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24621 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Howard McCay Cc: "24621@debbugs.gnu.org" <24621@debbugs.gnu.org> Received: via spool by 24621-submit@debbugs.gnu.org id=B24621.15731832243869 (code B ref 24621); Fri, 08 Nov 2019 03:21:02 +0000 Received: (at 24621) by debbugs.gnu.org; 8 Nov 2019 03:20:24 +0000 Received: from localhost ([127.0.0.1]:44304 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iSuox-00010K-MO for submit@debbugs.gnu.org; Thu, 07 Nov 2019 22:20:23 -0500 Received: from host.gofardesign.uk ([208.79.239.190]:54673) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iSuow-0000zu-12; Thu, 07 Nov 2019 22:20:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=marxist.se; s=default; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=hyLpzwldy/A0IYjvNhD3KiFKPE03JavsmqHkVYye3fw=; b=UIakus/nzT4qV1n3OoVSKdyZxE u2hS2TMr2pF/QuZcjj1QmGcqD5wkBKqVxDhcbk7dOfInpOd+3M7If8eLBozU6wMyV8SV5NBUhuzTH d0SX3k/HxkYlhXHebXIzODAevUYuQw1gRSeOyHg03WQIpEi6/ffNHwE5rmwaYYzYIUOU=; Received: from h-70-69.a785.priv.bahnhof.se ([155.4.70.69]:53820 helo=localhost) by host.gofardesign.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iSuop-00019O-Rh; Thu, 07 Nov 2019 21:20:16 -0600 From: Stefan Kangas In-Reply-To: <464741169.1690694.1476055344006@mail.yahoo.com> (Howard McCay's message of "Sun, 9 Oct 2016 23:22:23 +0000 (UTC)") 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> <1818766431.2865153.1475651705954@mail.yahoo.com> <87int76oki.fsf@zigzag.favinet> <464741169.1690694.1476055344006@mail.yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Date: Fri, 08 Nov 2019 04:20:14 +0100 Message-ID: <87mud7vytt.fsf@marxist.se> MIME-Version: 1.0 Content-Type: text/plain X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.gofardesign.uk X-AntiAbuse: Original Domain - debbugs.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - marxist.se X-Get-Message-Sender-Via: host.gofardesign.uk: authenticated_id: stefan@marxist.se X-Authenticated-Sender: host.gofardesign.uk: stefan@marxist.se X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) tags 24621 + wontfix close 24621 thanks Howard McCay 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