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 14:01: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> < <08a346aa-2bbc-6ecb-9286-6d9d4a72b25c@lanl.gov> 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 1473282101 17751 195.159.176.226 (7 Sep 2016 21:01:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 7 Sep 2016 21:01:41 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Davis Herring Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 07 23:01:32 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 1bhjyG-0002pC-GM for ged-emacs-devel@m.gmane.org; Wed, 07 Sep 2016 23:01:24 +0200 Original-Received: from localhost ([::1]:43011 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhjyE-00053F-Fw for ged-emacs-devel@m.gmane.org; Wed, 07 Sep 2016 17:01:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49583) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhjy5-000533-Qj for emacs-devel@gnu.org; Wed, 07 Sep 2016 17:01:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhjy0-0000UT-TM for emacs-devel@gnu.org; Wed, 07 Sep 2016 17:01:13 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:48695) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhjy0-0000UP-Is for emacs-devel@gnu.org; Wed, 07 Sep 2016 17:01:08 -0400 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u87L16QB012075 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2016 21:01:07 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u87L151D029895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2016 21:01:05 GMT Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u87L14ub012193; Wed, 7 Sep 2016 21:01:05 GMT In-Reply-To: <08a346aa-2bbc-6ecb-9286-6d9d4a72b25c@lanl.gov> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6753.5000 (x86)] X-Source-IP: userv0021.oracle.com [156.151.31.71] 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:207280 Archived-At: > >> a _form_ (hopefully less ambiguous than "expression"), > > > > (No less ambiguous.) >=20 > Why not? It's defined in the Emacs Lisp Reference Manual, and it's > not a generic term of art from parsing in a variety of contexts. I already addressed that. Again: In the Elisp manual, node `Intro Eval', "form" is given as a synonym for "expression". And both are mentioned as synonyms for both "S-expression" and "sexp" (which the manual generally avoids using). > > 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. >=20 > And thus a user who was expecting to enter the cons (comment-column . > 40) would be surprised, would they not, when the completion chose > something else? Unless `comment-column' has also been given a function definition in the user's session, completion of `comment-c' after `(' would not provide `comment-column' as a candidate. This has all been said multiple times now. But a user could type `(2 commment-c', `TAB' to complete to `(2 comment-column', and then remove the 2. For a long name that is not memorized, such completion can help. And for a variable or function name in the current buffer, `M-/' and `C-M-/' provide completion anywhere, including just after `('. Again, for a long name, such completion can help, regardless of whether the sexp read is evaluable without error. And using completion or not, a user can certainly enter `(comment-column . 4)', and that dotted list is what is returned by `read--expression'. This has all been covered already in this thread. Why do you reply to: It's clear that the completion it provides is for function names after `('. No one disputes that. by belaboring that point, as if you are divulging it? TAB completion of a name after `(' is function-name completion. Yes, and so what? `read--expression' is not _limited_ to reading only function names after `('. > Isn't that enough of a reason to acknowledge the function's > predisposition towards reading forms, not general values? Predisposition for completing a function name after `('. It is not limited to reading list sexps that only have a function-name car. > > And what it reads and returns is not limited by the (handy, > > for some expressions) completion it provides. >=20 > No one is questioning its _capacity_ to accept other data > from the user. And no one is questioning that it provides function-name (only) completion after `('. > (But if capacity is all that matters, you might as well use a normal > `read-from-minibuffer' and call `read' on the result yourself.) That's the point of this thread. No. `read--expression' is handier for many sexps, including some that are not lists with function-name cars. It's not black-&-white. Each read function, according to what it actually does, has its own advantages and use cases. The point (#1) is that the useful uses of `read--expression' are not limited to reading lists with function-name cars. In some contexts, completion of function and variable names can be useful for reading other sexps. And the point (#2) is that the usefulness of `read--expression' is not limited to Emacs developers - it should not be considered "internal". > > And even that completion says nothing about the intended use of > > what is read, in particular about any intention to evaluate it. >=20 > Nonsense -- that choice of completion mechanism, coupled with the choice > of the caller to use a function that provides it, indicates plainly that > the code's author meant for a form to be entered. It's not about the author of `read--expression'. It's about its users and their intentions. Why particular code reads a sexp - any sexp, is up to it. You cannot assume that it will then be evaluated by that code. And that stands for any read function, including `read--expression'. > >> 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. >=20 > No backtracking: I already said "could possibly evaluate". No > dotted list (e.g., (/ 3 . 0)) can ever evaluate. > You can also determine that the list (3 0 /) will not evaluate > successfully without any semantic understanding, because 3 is > not a function. Somewhat less reliably, we > can determine that the list (comment-column 40) will fail under > evaluation because `comment-column' is void as a function. But none of that is what `read--expression' does. It happily reads (/ 3 . 0), (3 0 /), (comment-column 40), and (comment-column . 40). What it does not accept (it raises an error) is a syntax error, i.e., a Lisp _read_ error, such as an isolated `.' or `,'. What it does is read and return a Lisp sexp, and not only one that `eval' can handle without error. And what if your code even _does_ intend to evaluate a sexp read, but only after its symbol car gets defined? Will your "improved" `read--expression' be right in not accepting (foo 42) because, at the moment of reading, `foo' is not yet defined? So much for its guessing intention of evaluation. > > 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". >=20 > In that context, "expression" is set against "object" and plainly refers > to the textual representation. (This is why I switched to the word > "form"!) (Again ((elisp) `Intro Eval'), for Emacs, "form"=3D"expression".) And yes, of course it is setting "expression" against "object". That's what a Lisp read function does, and `read--expression' is no exception. In the language of Common Lisp (CLTL2, 22.1.1), the Lisp reader "accept[s] characters, interpret[s] them as the printed representation of a Lisp object, and construct[s] and return[s] such an object." > > A better interpretation is based on what the function actually > > does, I think: what it reads without error and what it returns. >=20 > "Actually does" is a poor choice. Info that helps the user about what `read--expression' does: . It reads a Lisp sexp from the minibuffer. . For symbol names, it provides completion using `TAB'. . For a symbol name after `(', only function names are completed using `TAB'. (Function in the wide sense: macro, special-form, function.) . For a symbol name anywhere else, function and variable names are completed using `TAB'. (And `M-/' and `C-M-/' complete to names from the current buffer.) > > `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. >=20 > So you find the (undefined) behavior of its current implementation > useful. =20 > > What if you start relying on it and then someone else changes > it to do the sanity checks I discuss above (because, say, they want to > get better error messages than the evaluator gives, or they want to stop > the user from exiting the minibuffer with invalid input)? We'll cross that bridge when we come to it. For now, the only request has been to remove the extra hyphen and not consider it "internal", please. > That's why we have the documented contract Sorry, I must have missed that "documented contract". Where is it? What does `C-h f read--expression' tell you? "Not documented." You said that the behavior is undefined. So I say look at what it does. > -- to let us know whether you were in error to rely on it for > "off-label" uses,=20 Sorry, where's the label? ("Not documented.") > or whether the implementer was in error to alter it. We may choose > that contract at our whim -- and at our peril. There's no reason to > suppose that the answer is "whatever it currently implements, exactly", What reason is there to suppose that the nonexistent contract would say, if it existed, that the answer is "whatever Davis says"? > and less than no reason to choose "help the user type a form, > but do not check its validity in any way in case the caller is > expecting something else". In the absence of any "documented contract", we can go by what the function does. Or we can go by what you happen to think the function really wants to do but does not do. So far, I'm content with what `read--expression' does and does not do. But it should be considered just as useful for an ordinary Emacs user-programmer as it is for Emacs developers: not "internal".