* Definition of a sexp @ 2025-01-08 19:30 Heime via Users list for the GNU Emacs text editor 2025-01-08 21:12 ` [External] : " Drew Adams 0 siblings, 1 reply; 4+ messages in thread From: Heime via Users list for the GNU Emacs text editor @ 2025-01-08 19:30 UTC (permalink / raw) To: Heime via Users list for the GNU Emacs text editor In https://emacsdocs.org/docs/elisp/Parsing-Expressions a sexp is described as either a balanced parenthetical grouping, a string, or a symbol. Is this description correct? Is there a reason why a word or symbol in considered a sexp? ^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: [External] : Definition of a sexp 2025-01-08 19:30 Definition of a sexp Heime via Users list for the GNU Emacs text editor @ 2025-01-08 21:12 ` Drew Adams 2025-01-08 22:04 ` Heime via Users list for the GNU Emacs text editor 0 siblings, 1 reply; 4+ messages in thread From: Drew Adams @ 2025-01-08 21:12 UTC (permalink / raw) To: Heime, Heime via Users list for the GNU Emacs text editor > 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. > 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. 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). ^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: [External] : Definition of a sexp 2025-01-08 21:12 ` [External] : " Drew Adams @ 2025-01-08 22:04 ` Heime via Users list for the GNU Emacs text editor 2025-01-08 23:54 ` Drew Adams 0 siblings, 1 reply; 4+ messages in thread From: Heime via Users list for the GNU Emacs text editor @ 2025-01-08 22:04 UTC (permalink / raw) To: Drew Adams; +Cc: Heime via Users list for the GNU Emacs text editor 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). ^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: [External] : Definition of a sexp 2025-01-08 22:04 ` Heime via Users list for the GNU Emacs text editor @ 2025-01-08 23:54 ` Drew Adams 0 siblings, 0 replies; 4+ messages in thread From: Drew Adams @ 2025-01-08 23:54 UTC (permalink / raw) To: Heime; +Cc: Heime via Users list for the GNU Emacs text editor > Can one then state that a sexp is either a balanced parenthetical > grouping, a string, or a symbol, that is subject to evaluation? I already told you what a sexp is, and why "basically" is used there - it just means there that those are important kinds of sexps. IOW, that's not an exhaustive list. It might have added "a number" and "a vector" to the list, as other important kinds of atom. What "basically" does NOT mean there is that there are lists, strings, or symbols that aren't sexps. Of course you can pick nits such as representations of lists, strings, and symbols within comments or inside strings,... A sexp is a cons or an atom. That's the whole story. Read the rest of what I wrote or pointed you to, if you want details. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-01-08 23:54 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-01-08 19:30 Definition of a sexp Heime via Users list for the GNU Emacs text editor 2025-01-08 21:12 ` [External] : " Drew Adams 2025-01-08 22:04 ` Heime via Users list for the GNU Emacs text editor 2025-01-08 23:54 ` Drew Adams
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).