RE: `read--expression' and `read-minibuffer'

[Drew Adams <drew.adams@oracle.com>]

> > 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.
> 
> 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, 
> `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 
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.
> 
> 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.)
> 
> 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".
> 
> 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".