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: Wed, 7 Sep 2016 09:02:03 -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 1473264389 10884 195.159.176.226 (7 Sep 2016 16:06:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 7 Sep 2016 16:06:29 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: "Herring, Davis" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 07 18:06:25 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 1bhfMh-0001tv-6f for ged-emacs-devel@m.gmane.org; Wed, 07 Sep 2016 18:06:19 +0200 Original-Received: from localhost ([::1]:41868 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhfMf-0000ll-3z for ged-emacs-devel@m.gmane.org; Wed, 07 Sep 2016 12:06:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54596) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhfIp-0006Gv-UK for emacs-devel@gnu.org; Wed, 07 Sep 2016 12:02:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhfIm-0003ZI-NE for emacs-devel@gnu.org; Wed, 07 Sep 2016 12:02:19 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:41010) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhfIm-0003YA-Eb for emacs-devel@gnu.org; Wed, 07 Sep 2016 12:02:16 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u87G2CgT006210 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2016 16:02:14 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u87G2CY4001020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2016 16:02:12 GMT Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u87G254m005458; Wed, 7 Sep 2016 16:02:11 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: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 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:207249 Archived-At: > > 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. >=20 > It affects completion, as has already been stated: given > (comment-c as a _form_ (hopefully less ambiguous than "expression"), (No less ambiguous.) > the only completion is `comment-choose-indent'; as a general s-exp,=20 > `comment-column' is probably more likely. All of that has already been said, by each of us. I said it at the outset. It's clear that the completion it provides is for function names after `('. No one disputes that. What `read--expression' reads and returns says nothing about any particular intention to evaluate. And what it reads and returns=20 is not limited by the (handy, for some expressions) completion it provides. And even that completion says nothing about the intended use of what is read, in particular about any intention to evaluate it. This has all been said before in this thread. > > 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. >=20 > They have a structure that could possibly evaluate without error? Is that really how you want to define "expression"? So `(/ 3 0)' is not an expression, _because_ it raises an arithmetic error? Or do you want to backtrack a bit, and settle on just syntax errors? Or on some other kind of error? See my previous message about this. > Of course, nothing can check that an evaluation completes without error > (without actually evaluating it, which might never complete). So `read-- > expression' doesn't bother checking at all. Of course. And where does that leave your attempt to define "expression" in terms of evaluation non-error? And what makes you assume that it would if it could, that is, that it even cares only about expressions that could be evaluated without error? Why not accept it for what it is - characterize it by its actual behavior (which is to read any syntactically valid sexp). What it does is similar to what `read' does. The difference is that it reads from the minibuffer, providing handy completion, in particular for some kinds of expressions. And note that the doc of `read' too talks about reading a "Lisp expression". It does not exclude `((a . b) (c . d))' or any other syntactically valid sexp from the class of "expressions". In fact, the behavior of `read' - the behavior of the Lisp reader, _defines_ syntactic validity. It defines what is an "expression", aka "sexp", and what is not, I think. > > Does `read--expression' complain that what it read here is > > not an "Elisp expression"? (Nope.) >=20 > It is better to interpret `read--expression' not as "read and return a > form" but rather as "read an s-exp from the user, helping them type a > form". So you say. But why is it better to interpret things as you choose to interpret them? A better interpretation is based on what the function actually does, I think: what it reads without error and what it returns. > It really is a question of intent: the caller intends to get a > form, so they make it easy for the user (who is hopefully also > intending to enter a form) to do so. ["they" are > "expression"/"form" and "sexp"] So you say, with nothing but hand-waving to back it up. That's presumptuous about what a caller wants to get from the user and what it wants to do with what it gets. Instead, look at what the function actually reads (without error) and what it actually returns. There is no such limitation in its _behavior_ as what you propose/intend. `read-expression' is handy for reading lots of sexps that do not fit your characterization of intent - simply because that's what it actually does: reads and returns a sexp. > > Apparently, in Emacs-Speak, they are the same. They are > > distinguished from the more general category of Lisp "objects". >=20 > Be careful with the map and the territory: a string for the Lisp reader > isn't itself a (Lisp) object unless it also exists as a string object in > Lisp. An object results from a read of an s-exp; the words "expression" > and "form" are commonly applied both to the object read (if it "seems" > evaluable) and to the read syntax for it, but the word "object" is not. We're not (so far, but if you insist then we can also go down that path) distinguishing representation from represented, here. Is a sexp or an expression text on paper, characters in a buffer or in a string? Is it something that only _represents_ a Lisp object? Or is it a Lisp object? Is what is read by `read--expression' (or by any read) a sexp/expression? Or is that what is returned by it? Or both? Is this a string: "abc"? Or does a string result only from reading that text? It's not necessary to make this representation/represented distinction _here_, but if you insist, then go for it. Stake out clearly what is representation and what is represented, and relate what you come up with to the behavior of `read-expression'. _My_ question is only about `read--expression'. To me, it is handy for ordinary user-programmers, not just for Emacs developers, and it should not be considered "internal". To me, even though it provides function-name completion after `(' and both function- and variable-name completion otherwise, it is useful not only for reading function applications and other forms that can be evaluated without error, but also other sexps that cannot. You can limit yourself to using it only for the former, if you like, but that's not what the function does, so its users are not limited to any such "intention".