From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Heime via Users list for the GNU Emacs text editor Newsgroups: gmane.emacs.help Subject: RE: [External] : Definition of a sexp Date: Wed, 08 Jan 2025 22:04:40 +0000 Message-ID: References: Reply-To: Heime Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9635"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Heime via Users list for the GNU Emacs text editor To: Drew Adams Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jan 08 23:06:20 2025 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tVeBv-0002Ic-G2 for geh-help-gnu-emacs@m.gmane-mx.org; Wed, 08 Jan 2025 23:06:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tVeAX-0004FZ-3l; Wed, 08 Jan 2025 17:04:53 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tVeAU-0004F8-PF for help-gnu-emacs@gnu.org; Wed, 08 Jan 2025 17:04:51 -0500 Original-Received: from mail-4319.protonmail.ch ([185.70.43.19]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tVeAR-0006Qv-UN for help-gnu-emacs@gnu.org; Wed, 08 Jan 2025 17:04:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736373885; x=1736633085; bh=TDLZMyzbLe9YlJtWnu4T9JT/GreuWVOYW1UTLTinVaA=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=yu4I1yeI/Qb6+GsVMPBSGkOp8+3px1VoJO84mi3zu+HztTndcIjRTY8Dm4h/c9mkW 4AteWAQGhP8opi/40q6aU8zljLy7tswa/AVeeumDLgCpS1T9AUg9UuRuJ/WEZpZUS4 mUvrwcuaPIXCnHd+Pz2RGeCADsLYFEXtSYXYmasF72e27RWeVj5+E90+lvAy8A2SCd i41PEe0cC9culuMpLY+eFgjhgnZTT/ZgYfyRVRo1vigjlrarafNR3sYTmV/J7pinBc ekz7qUfo86LtDNp4CqlaEHeTDl8KCnQCUpUdcjfSHDEmaMNyhDIphOSs/J44PSaoBB YSGeiMFvXBVnA== In-Reply-To: Feedback-ID: 57735886:user:proton X-Pm-Message-ID: 59fd95915d382418d1aee610e4dc76e3fca8c902 Received-SPF: pass client-ip=185.70.43.19; envelope-from=heimeborgia@protonmail.com; helo=mail-4319.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:149172 Archived-At: On Thursday, January 9th, 2025 at 9:12 AM, Drew Adams wrote: > > In elisp/Parsing-Expressions a sexp is described > > as either a balanced parenthetical grouping, a > > string, or a symbol. >=20 >=20 > Very good to see you're reading the docs. Thanks > for helping yourself this way. >=20 > > Is this description correct? >=20 >=20 > Yes. Why should we doubt it? Actually, it > doesn't say what you say it says. It says this: >=20 > Basically, a sexp is either a balanced parenthetical > grouping, a string, or a symbol... >=20 > 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,=20 or a symbol, is falsiable. Thus it would also be incorrect to=20 read it and consider a sexp as described. =20 It would be an improvement to state some circumstances when a description as defined does not constitute a sexp. Does the=20 exception likely to happen for strings or can this also happen=20 for parenthetical groups? > > Is there a reason why a word or symbol in considered a sexp? >=20 >=20 > 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. >=20 > 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). >=20 > 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.=20 > 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. >=20 > Any Lisp sexp that isn't a cons is an atom. > Predicates `atom' and` consp' are exact opposites. > ___ >=20 > Start with the Emacs manual. Its Glossary has > this entry for `sexp': A sexp (short for =E2=80=9Cs-expression=E2=80= =9D) 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 = =E2=80=98sexp=E2=80=99 in their name. *Note Sexps: Expressions. That link a= t the end sends you to node` Expressions'. >=20 > 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. >=20 > 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. >=20 > 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 no= de tells you: A Lisp object that is intended for evaluation is called a ^^^= ^^^^^^^^^^^^^^^^^^^^ =E2=80=9Cform=E2=80=9D or =E2=80=9Cexpression=E2=80= =9D(1). The fact that forms are data ^^^^^^^^^^^^^^ objects and not merely = text is one of the fundamental ^^^^^^^^^^^^^^^ differences between Lisp-lik= e languages and typical programming languages. Any object can be evaluated,= but in practice only numbers, symbols, lists and strings are evaluated ver= y often. A more pedantic/rigorous statement might separate syntax (text) fr= om 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 no= de titled "Introduction to Evaluation". Forms/sexps _are_ text, but they're= not _merely_ text. The code text you write corresponds pretty much directl= y with the underlying code objects that get evaluated. The Lisp _interprete= r_ doesn't evaluate text. The Lisp _reader_ reads text to get Lisp objects.= The interpreter evaluates Lisp objects. Lisp syntax is simple. It essentia= lly shows you the bare bones of the underlying objects - there's very littl= e 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", "for= ty-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).