RE: [External] : Definition of a sexp

[Heime via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>]

On Thursday, January 9th, 2025 at 9:12 AM, Drew Adams <drew.adams@oracle.com> wrote:

> > In elisp/Parsing-Expressions a sexp is described
> > as either a balanced parenthetical grouping, a
> > string, or a symbol.
> 
> 
> Very good to see you're reading the docs. Thanks
> for helping yourself this way.
> 
> > Is this description correct?
> 
> 
> Yes. Why should we doubt it? Actually, it
> doesn't say what you say it says. It says this:
> 
> Basically, a sexp is either a balanced parenthetical
> grouping, a string, or a symbol...
> 
> That qualifier "basically" is important, if you
> ask whether the description is "correct". It's
> correct if you include "basically". It's not
> completely correct if you omit it. But this is
> a detail/nit.

If I include _basically_ it suggests to me that the description
that a sexp is either a balanced parenthetical grouping, a string, 
or a symbol, is falsiable.  Thus it would also be incorrect to 
read it and consider a sexp as described.  

It would be an improvement to state some circumstances when a
description as defined does not constitute a sexp.  Does the 
exception likely to happen for strings or can this also happen 
for parenthetical groups?

> > Is there a reason why a word or symbol in considered a sexp?
> 
> 
> Yes. Or rather, a symbol is a sexp, but a word
> is not. A word isn't recognized as a Lisp object
> or as the representation of a Lisp object.
> 
> And a numeral, and a string representation, and
> a vector representation, and a list (cons)
> representation... Those are all sexps. They all
> represent Lisp objects (numbers, strings, vectors,
> conses).
> 
> They are the syntactic elements of Emacs Lisp, or
> more precisely the syntactic elements that are
> subject to evaluation (unlike, e.g., comments).
> This is how you know, for instance, that a word
> isn't a sexp - it's not an object for evaluation.

Can one then state that a sexp is either a balanced parenthetical
grouping, a string, or a symbol, that is subject to evaluation?

If so, we could get rid of the basically and provide a more
accurate description that would benefit everyone. 

> Lisp is composed of atoms and conses (lists,
> including dotted lists). Nothing more. A
> string is an atom. So is a symbol, a vector, a
> number, etc.
> 
> Any Lisp sexp that isn't a cons is an atom.
> Predicates `atom' and` consp' are exact opposites.
> ___
> 
> Start with the Emacs manual. Its Glossary has
> this entry for `sexp': A sexp (short for “s-expression”) is the basic syntactic unit of Lisp in its textual form: either a list, or Lisp atom. Sexps are also the balanced expressions (q.v.) of the Lisp language; this is why the commands for editing balanced expressions have ‘sexp’ in their name. *Note Sexps: Expressions. That link at the end sends you to node` Expressions'.
> 
> That definition doesn't distinguish a textual
> representation from what it represents. We call
> the text "(foo bar 42)" a "list". We also call
> the Lisp object represented by that text a list.
> 
> There's a reason we do that, and a reason we can
> get away with doing that, and it's one of the
> beauties of Lisp - see below.
> 
> That `sexp' glossary entry is also linked from the _Elisp_ manual, where it introduces "form" aka "expression" aka "S-expression" aka "sexp". https://www.gnu.org/software/emacs/manual/html_node/elisp/Intro-Eval.html That node tells you: A Lisp object that is intended for evaluation is called a ^^^^^^^^^^^^^^^^^^^^^^^ “form” or “expression”(1). The fact that forms are data ^^^^^^^^^^^^^^ objects and not merely text is one of the fundamental ^^^^^^^^^^^^^^^ differences between Lisp-like languages and typical programming languages. Any object can be evaluated, but in practice only numbers, symbols, lists and strings are evaluated very often. A more pedantic/rigorous statement might separate syntax (text) from Lisp objects represented by it. But that passage tries to indicate/hint that Lisp text pretty much _directly_ provides access to Lisp objects that can be evaluated (aka forms aka sexps). It's fitting that this is in the node titled "Introduction to Evaluation". Forms/sexps _are_ text, but they're not _merely_ text. The code text you write corresponds pretty much directly with the underlying code objects that get evaluated. The Lisp _interpreter_ doesn't evaluate text. The Lisp _reader_ reads text to get Lisp objects. The interpreter evaluates Lisp objects. Lisp syntax is simple. It essentially shows you the bare bones of the underlying objects - there's very little between the two. It's at least as close as the pair numeral/number: When you see the text "42" written (a numeral), you think of the number 42. Only semanticists clarify that a numeral is a name for a number. "XXXXII", "forty-two", and "quarante-deux" are other names for the same number. In Lisp,` (42)' is a cons, whether you think of it as a
> pair of pointers (car and cdr) plus a `nil' atom or you
> think of it as text that has a left paren a numeral,
> and a right paren (possibly with intervening whitespace).