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

[Herring, Davis]

[Many variations of the following points snipped.]

> 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"), the only completion 
is `comment-choose-indent'; as a general s-exp, `comment-column' is probably 
more likely.

> 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?  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.

> 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".  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"]
> 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.

Davis