all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Heime <heimeborgia@protonmail.com>,
	Heime via Users list for the GNU Emacs text editor
	<help-gnu-emacs@gnu.org>
Subject: RE: [External] : Definition of a sexp
Date: Wed, 8 Jan 2025 21:12:55 +0000	[thread overview]
Message-ID: <DS7PR10MB52329E395A30120CE42938D7F3122@DS7PR10MB5232.namprd10.prod.outlook.com> (raw)
In-Reply-To: <ApVU-W-SGaQ7zVbGF-viK8cwn2-3DHBX9MjVy7RLHGo0oZMayu2aur0QNhDzNcPDz86uVKoQu-P26GL3xfmnXuvp6Bh07QOToRcIOH90aqs=@protonmail.com>

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

  reply	other threads:[~2025-01-08 21:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2025-01-08 22:04   ` [External] : " Heime via Users list for the GNU Emacs text editor
2025-01-08 23:54     ` Drew Adams
2025-01-09 23:06       ` uzibalqa via Users list for the GNU Emacs text editor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DS7PR10MB52329E395A30120CE42938D7F3122@DS7PR10MB5232.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=heimeborgia@protonmail.com \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.