[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: `read--expression' and `read-minibuffer'
From: |
Stefan Monnier |
Subject: |
Re: `read--expression' and `read-minibuffer' |
Date: |
Tue, 06 Sep 2016 23:46:44 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) |
> 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
- RE: `read--expression' and `read-minibuffer', (continued)
- RE: `read--expression' and `read-minibuffer', Drew Adams, 2016/09/04
- Re: `read--expression' and `read-minibuffer', Stefan Monnier, 2016/09/04
- RE: `read--expression' and `read-minibuffer', Drew Adams, 2016/09/04
- Re: `read--expression' and `read-minibuffer', Stefan Monnier, 2016/09/04
- Re: `read--expression' and `read-minibuffer', Davis Herring, 2016/09/06
- Re: `read--expression' and `read-minibuffer', Stefan Monnier, 2016/09/06
- RE: `read--expression' and `read-minibuffer', Drew Adams, 2016/09/06
- RE: `read--expression' and `read-minibuffer', Drew Adams, 2016/09/06
- Re: `read--expression' and `read-minibuffer', Stefan Monnier, 2016/09/06
- RE: `read--expression' and `read-minibuffer', Drew Adams, 2016/09/06
- Re: `read--expression' and `read-minibuffer',
Stefan Monnier <=
- RE: `read--expression' and `read-minibuffer', Drew Adams, 2016/09/07
- RE: `read--expression' and `read-minibuffer', Herring, Davis, 2016/09/07
- RE: `read--expression' and `read-minibuffer', Drew Adams, 2016/09/07
- Re: `read--expression' and `read-minibuffer', Davis Herring, 2016/09/07
- RE: `read--expression' and `read-minibuffer', Drew Adams, 2016/09/07
- Re: `read--expression' and `read-minibuffer', Stefan Monnier, 2016/09/09
- RE: `read--expression' and `read-minibuffer', Drew Adams, 2016/09/09
- Re: `read--expression' and `read-minibuffer', Michael Heerdegen, 2016/09/07
- Re: `read--expression' and `read-minibuffer', Stefan Monnier, 2016/09/07
- Re: `read--expression' and `read-minibuffer', Michael Heerdegen, 2016/09/07