From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: `read--expression' and `read-minibuffer' Date: Tue, 6 Sep 2016 22:54:10 -0700 (PDT) Message-ID: References: <60e5e890-6f50-4f38-a74f-e82ff83b24dc@default> <8e6be928-75ae-4714-bf03-d6505954cf21@default> <10888855-8ce3-648f-82ac-2b9e1409effc@lanl.gov> <91f3ab85-e033-4e1d-a3c2-66c964ea82bc@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1473227712 30850 195.159.176.226 (7 Sep 2016 05:55:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 7 Sep 2016 05:55:12 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 07 07:55:08 2016 Return-path: Envelope-to: ged-emacs-devel@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 1bhVp4-0006af-Q3 for ged-emacs-devel@m.gmane.org; Wed, 07 Sep 2016 07:54:59 +0200 Original-Received: from localhost ([::1]:38148 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhVp2-0003WZ-LS for ged-emacs-devel@m.gmane.org; Wed, 07 Sep 2016 01:54:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48524) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhVoU-0003WT-9x for emacs-devel@gnu.org; Wed, 07 Sep 2016 01:54:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhVoR-0007bw-4E for emacs-devel@gnu.org; Wed, 07 Sep 2016 01:54:22 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:41782) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhVoQ-0007bo-QX for emacs-devel@gnu.org; Wed, 07 Sep 2016 01:54:19 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u875sG5m031245 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 7 Sep 2016 05:54:17 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id u875sEFK025033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2016 05:54:15 GMT Original-Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u875sDAO020302; Wed, 7 Sep 2016 05:54:14 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6753.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:207239 Archived-At: > > Your analogy is OK. I wouldn't speak of an "Elisp expression" > > here, since to me that just means any expression - sexp that > > you can construct with Emacs Lisp. >=20 > What would you call it then? > What did you expect an "Elisp expression" to mean when contrasted to an > "S-exp"? I really can't understand how you could have gotten confused. You spoke of intention to evaluate, as I said. I didn't, and still don't, see how such an intention enters into what `read--expression' does. I don't even know what such intention means, operationally. I can see how the Lisp _reader_ does not accept certain Lisp objects, so such errors raised can be considered syntax errors, just as trying to read an isolated comma or period. But if you bring in evaluation to further classify Lisp objects then please tell us exactly how those that you call "expression" differ with respect to evaluation. And after that, please bring in the notion of an "intention" to evaluate. Finally, please relate all of that to what `read--expression' actually does, which is what I was/am interested in. I think you'll find that you'll be going in circles and waving your hands. I would be too, if I were trying to nail down such things. > > See above. Any Lisp sexp can be related to Elisp code. Any data > > can be a piece of some code. >=20 > That's irrelevant. 'int b*;' and 'a[b' can appear in a C program, but > they're not C expressions. Similarly, ((a . 2) (b . 3)) is *not* an > Elisp expression, regardless of whether it can appear inside an > Elisp expression. Adding emphasis doesn't make it any more evident, I'm afraid. (And Lisp is not C.) You haven't defined Elisp expression, except to say that it is a sexp that you intend to evaluate. Is (foo 2) an Elisp expression? Even if `foo' is not a defined function? Or if it is defined but evaluating (foo 2) raises an error? What does this tell you? (read--expression "Sexp: ") Type: ((a . 2) (b . 3)) Does `read--expression' complain that what it read here is not an "Elisp expression"? (Nope.) I'll not quibble over the (as yet undefined and unclear) terms you use. You asked why the confusion. I've told you. I said from the beginning that I was talking about what `read--expression' reads and returns. > > It's what Davis was trying to distinguish `read--expression' as: > > reading an expression "intended for evaluation" (paraphrasing). >=20 > I don't think I talked about "expression" intended for evaluation > but "S-exp" intended for evaluation. Perhaps. I identified the two; mea culpa. But I do see now that (elisp) `Intro Eval' defines "expression" and "form" as "a Lisp object that is intended for evaluation". So I can see where you're coming from. (I don't see there, either, how such "intention" is defined, however. To me, this is as vague as your use of it.) On the other hand, it adds: "It is sometimes referred to as an "S-expression" or "sexp", but we generally do not use this terminology in this manual." It is standard Lisp terminology (from McCarthy's first paper, even, IIRC), but that's no matter. At least you can see, I hope, my "confusion": the two are indeed the same, even in Emacs parlance. (And AFAICT, they correspond to what `read--expression' reads and returns.) Apparently, in Emacs-Speak, they are the same. They are distinguished from the more general category of Lisp "objects". I gather that the latter, or at least some of the latter, are what you have been calling "S-exps". > For me the name "expression" already tends to have a connotation of > being a piece of code that can be evaluated (e.g. in contexts where > you'd also see related concepts like declaration, instruction, data, > ...), so I use "S-exp" to make it clear I'm only talking about the > XML-like syntactic level independent from any associated semantic. I gathered that, but it was not clear at the outset. And your terms "expression" and "S-exp" apparently correspond to what Emacs calls "expression" and Lisp "object", respectively, whereas it says that "expression" and "S-exp" are the same (and that the manual does not use "S-exp"/"sexp" - but Emacs does elsewhere).=20 > > Likewise, you. You both tried to distinguish what it does as > > reading an expression that might be evaluated (even though it can > > also read expressions that cannot, without raising an error). >=20 > How else would you describe the difference between > - a thingy that uses the Elisp reader syntax and whose semantics > we know nothing about. > - that same thingy but knowing that it's a chunk of Elisp code. > ? Define "knowing that it's a chunk of Elisp code". Does it mean that `eval' does not raise an error? That it does not raise certain kinds of error? Is any thing acceptable to the Lisp reader a potential "chunk of Elisp code"? Why not? > > I don't have a name for that. "Expression" doesn't > > say more than "sexp", to me - it's just as general. And for Emacs too, apparently. On this, at least, Emacs and I apparently speak with the same terms. > If we confuse those two concepts somewhere, it's a bug. At any rate, my interest was with what `read--expression' reads and returns. Call that what you like. And `read--expression' reads and returns the Lisp object ((a . 2) (b . 3)) just fine - a thing which you apparently exclude from your class of "expressions" but include in in your class of "sexps". So for you, it seems that `read--expression' does not necessarily read an expression. > >> > 1. That's not a good reason to make it "internal". > >> I already said that it's internal for no particular reason. > > Not really. You said that it's internal because it's easier to > > later make a name non-internal than the reverse. Which is true, > > but which is not a great reason, in itself: it would apply to > > every new function. >=20 > We violently agree: since it would apply to every function, > it's not a particular reason. I don't think we disagree, but we have at least been confusing each other with words. Getting better, I hope.