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

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

> > Your analogy is OK.  I wouldn't speak of an "Elisp expression"
> > here, since to me that just means any expression - sexp that
> > you can construct with Emacs Lisp.
> 
> What would you call it then?
> What did you expect an "Elisp expression" to mean when contrasted to an
> "S-exp"?  I really can't understand how you could have gotten confused.

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.

I can see how the Lisp _reader_ does not accept certain Lisp
objects, so such errors raised can be considered syntax errors,
just as trying to read an isolated comma or period.

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.

And after that, please bring in the notion of an "intention"
to evaluate.

Finally, please relate all of that to what `read--expression'
actually does, which is what I was/am interested in.

I think you'll find that you'll be going in circles and
waving your hands.  I would be too, if I were trying to
nail down such things.

> > See above.  Any Lisp sexp can be related to Elisp code.  Any data
> > can be a piece of some code.
> 
> That's irrelevant.  'int b*;' and 'a[b' can appear in a C program, but
> they're not C expressions.  Similarly, ((a . 2) (b . 3)) is *not* an
> Elisp expression, regardless of whether it can appear inside an
> Elisp expression.

Adding emphasis doesn't make it any more evident, I'm afraid.
(And Lisp is not C.)

You haven't defined Elisp expression, except to say that it
is a sexp that you intend to evaluate.  Is (foo 2) an Elisp
expression?  Even if `foo' is not a defined function?  Or if
it is defined but evaluating (foo 2) raises an error?

What does this tell you?

(read--expression "Sexp: ")
Type: ((a . 2) (b . 3))

Does `read--expression' complain that what it read here is
not an "Elisp expression"?  (Nope.)

I'll not quibble over the (as yet undefined and unclear)
terms you use.  You asked why the confusion.  I've told you.

I said from the beginning that I was talking about what
`read--expression' reads and returns.

> > It's what Davis was trying to distinguish `read--expression' as:
> > reading an expression "intended for evaluation" (paraphrasing).
> 
> I don't think I talked about "expression" intended for evaluation
> but "S-exp" intended for evaluation.

Perhaps.  I identified the two; mea culpa.

But I do see now that (elisp) `Intro Eval' defines "expression"
and "form" as "a Lisp object that is intended for evaluation".
So I can see where you're coming from.

(I don't see there, either, how such "intention" is defined,
however.  To me, this is as vague as your use of it.)

On the other hand, it adds: "It is sometimes referred to as
an "S-expression" or "sexp", but we generally do not use this
terminology in this manual."

It is standard Lisp terminology (from McCarthy's first paper,
even, IIRC), but that's no matter.  At least you can see, I
hope, my "confusion": the two are indeed the same, even in
Emacs parlance.  (And AFAICT, they correspond to what
`read--expression' reads and returns.)

Apparently, in Emacs-Speak, they are the same.  They are
distinguished from the more general category of Lisp "objects".

I gather that the latter, or at least some of the latter, are
what you have been calling "S-exps".

> For me the name "expression" already tends to have a connotation of
> being a piece of code that can be evaluated (e.g. in contexts where
> you'd also see related concepts like declaration, instruction, data,
> ...), so I use "S-exp" to make it clear I'm only talking about the
> XML-like syntactic level independent from any associated semantic.

I gathered that, but it was not clear at the outset.  And
your terms "expression" and "S-exp" apparently correspond to
what Emacs calls "expression" and Lisp "object", respectively,
whereas it says that  "expression" and "S-exp" are the same
(and that the manual does not use "S-exp"/"sexp" - but Emacs
does elsewhere). 

> > Likewise, you.  You both tried to distinguish what it does as
> > reading an expression that might be evaluated (even though it can
> > also read expressions that cannot, without raising an error).
> 
> How else would you describe the difference between
> - a thingy that uses the Elisp reader syntax and whose semantics
>   we know nothing about.
> - that same thingy but knowing that it's a chunk of Elisp code.
> ?

Define "knowing that it's a chunk of Elisp code".  Does it
mean that `eval' does not raise an error?  That it does not
raise certain kinds of error?

Is any thing acceptable to the Lisp reader a potential
"chunk of Elisp code"?  Why not?

> > I don't have a name for that.  "Expression" doesn't
> > say more than "sexp", to me - it's just as general.

And for Emacs too, apparently.  On this, at least, Emacs
and I apparently speak with the same terms.

> If we confuse those two concepts somewhere, it's a bug.

At any rate, my interest was with what `read--expression'
reads and returns.  Call that what you like.

And `read--expression' reads and returns the Lisp object
((a . 2) (b . 3)) just fine - a thing which you apparently
exclude from your class of "expressions" but include in
in your class of "sexps".  So for you, it seems that
`read--expression' does not necessarily read an expression.

> >> > 1. That's not a good reason to make it "internal".
> >> I already said that it's internal for no particular reason.
> > Not really.  You said that it's internal because it's easier to
> > later make a name non-internal than the reverse.  Which is true,
> > but which is not a great reason, in itself: it would apply to
> > every new function.
> 
> We violently agree: since it would apply to every function,
> it's not a particular reason.

I don't think we disagree, but we have at least been
confusing each other with words.  Getting better, I hope.