From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Davis Herring Newsgroups: gmane.emacs.devel Subject: Re: `read--expression' and `read-minibuffer' Date: Wed, 7 Sep 2016 11:01:40 -0600 Organization: XCP-1 Message-ID: <08a346aa-2bbc-6ecb-9286-6d9d4a72b25c@lanl.gov> 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; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1473267725 4555 195.159.176.226 (7 Sep 2016 17:02:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 7 Sep 2016 17:02:05 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 Cc: Stefan Monnier , emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 07 19:02:01 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 1bhgEW-0000EX-MG for ged-emacs-devel@m.gmane.org; Wed, 07 Sep 2016 19:01:56 +0200 Original-Received: from localhost ([::1]:42101 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhgEU-0001eE-Ls for ged-emacs-devel@m.gmane.org; Wed, 07 Sep 2016 13:01:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41960) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhgEO-0001e8-Fu for emacs-devel@gnu.org; Wed, 07 Sep 2016 13:01:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhgEJ-0007xa-6k for emacs-devel@gnu.org; Wed, 07 Sep 2016 13:01:47 -0400 Original-Received: from proofpoint5.lanl.gov ([2001:400:4210:400::a5]:45827) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhgEI-0007xF-Ju for emacs-devel@gnu.org; Wed, 07 Sep 2016 13:01:43 -0400 Original-Received: from mailrelay1.lanl.gov (mailrelay1.lanl.gov [128.165.4.101]) by mailgate5.lanl.gov (8.15.0.59/8.15.0.59) with ESMTP id u87H1esZ026577; Wed, 7 Sep 2016 11:01:40 -0600 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by mailrelay1.lanl.gov (Postfix) with ESMTP id C1838141DA57; Wed, 7 Sep 2016 11:01:40 -0600 (MDT) X-NIE-2-Virus-Scanner: amavisd-new at mailrelay1.lanl.gov Original-Received: from snares.lanl.gov (snares.lanl.gov [128.165.123.245]) by mailrelay1.lanl.gov (Postfix) with ESMTP id 9420D141DA4B; Wed, 7 Sep 2016 11:01:40 -0600 (MDT) In-Reply-To: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.154, 1.0.3, 0.0.0000 definitions=2016-09-07_07:2016-09-07, 2016-09-07, 1970-01-01 signatures=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 2001:400:4210:400::a5 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:207258 Archived-At: >> It affects completion, as has already been stated: given >> (comment-c as a _form_ (hopefully less ambiguous than "expression"), > > (No less ambiguous.) 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. > 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. 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? Isn't that enough of a reason to acknowledge the function's predisposition towards reading forms, not general values? > And what it reads and returns is not limited by the (handy, for > some expressions) completion it provides. No one is questioning its _capacity_ to accept other data from the user. (But if capacity is all that matters, you might as well use a normal `read-from-minibuffer' and call `read' on the result yourself.) > And even that completion says nothing about the > intended use of what is read, in particular about any intention > to evaluate it. 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. The only escape is the notion that the author used the function, despite a semantic mismatch, because there was no better choice available or because they didn't know about it. Either of those constitutes a bug -- the former of laziness, and the latter of ignorance. >> 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. 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. Rice's theorem, of course, denies most progress beyond that point: you can try to count arguments, for example, but as has been discussed recently that is fraught with peril in the case of advice-like function wrappers. We nonetheless can offer a rigorous definition of a form such that all expressions which evaluate without error are forms, even though not all forms evaluate without error (and some of them have variable behavior). > 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). That's like characterizing Emacs as a compiler because someone chooses to write an object file in it with C-q. The tailoring of the tool, not the result of its use in any particular instance, defines its purpose. > 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 that context, "expression" is set against "object" and plainly refers to the textual representation. (This is why I switched to the word "form"!) > A better interpretation is based on > what the function actually does, I think: what it reads without > error and what it returns. "Actually does" is a poor choice. `universal-argument' "actually returns" the "exit function" created by `set-transient-map'. But it doesn't document that behavior, because we prefer the flexibility of changing it to the (marginal) utility to the caller of `universal-argument'. (For example, in Emacs 23 it returns t; should the current implementation contain a stray "t" to retain that behavior?) > 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. What I have offered to "back it up" appears minuscule only in comparison to the redundant text arguing about it (much of it snipped here). > `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. So you find the (undefined) behavior of its current implementation useful. 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)? That's why we have the documented contract -- to let us know whether you were in error to rely on it for "off-label" uses, 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", 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". Davis -- This product is sold by volume, not by mass. If it appears too dense or too sparse, it is because mass-energy conversion has occurred during shipping.