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

[Stefan Monnier]

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

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

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

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.

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

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

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

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


        Stefan