Editing S-expression (section)

== Standardization ==
{{See also|Canonical S-expressions}}

Standards for some Lisp-derived programming languages include a specification for their S-expression syntax.  These include [[Common Lisp]] (ANSI standard document ANSI INCITS 226-1994 (R2004)), [[Scheme (programming language)|Scheme]] (R5RS and [[R6RS]]<ref>{{Cite journal|title=Revised6 Report on the Algorithmic Language Scheme|date=Aug 12, 2009|journal=Journal of Functional Programming|volume=19|issue=S1|pages=1–301|doi=10.1017/S0956796809990074|last1=Sperber|first1=Michael|last2=Dybvig|first2=R. Kent|last3=Flatt|first3=Matthew|last4=Van Straaten|first4=Anton|last5=Findler|first5=Robby|last6=Matthews|first6=Jacob|citeseerx=10.1.1.372.373|s2cid=267822156 }}</ref>), and [[ISLISP]].

In May 1997, [[Ron Rivest]] submitted an [[Internet Draft]]<ref>[https://web.archive.org/web/20230223024606/http://people.csail.mit.edu/rivest/Sexp.txt  S-expressions], Network Working Group, Internet Draft, Expires November 4, 1997 - R. Rivest, May 4, 1997 draft-rivest-sexp-00.txt, Ronald L. Rivest, CSAIL MIT website</ref> to be considered for publication as an [[Request for Comments|RFC]]. The draft defined a syntax based on Lisp S-expressions but intended for general-purpose data storage and exchange (similar to [[XML]]) rather than specifically for programming. It was never approved as an RFC, but it has since been cited and used by other RFCs (e.g. RFC 2693) and several other publications.<ref>[https://scholar.google.com/scholar?hl=en&lr=&safe=off&q=rivest+sexp&btnG=Search rivest sexp], Google Scholar (search)</ref> It was originally intended for use in [[Simple public key infrastructure|SPKI]].

Rivest's format defines an S-expression as being either an octet-string (a series of [[byte]]s) or a finite list of other S-expressions. It describes three interchange formats for expressing this structure. One is the "advanced transport", which is very flexible in terms of formatting, and is syntactically similar to Lisp-style expressions, but they are not identical. The advanced transport, for example, allows octet-strings to be represented verbatim (the string's length followed by a colon and the entire raw string), a quoted form allowing escape characters, [[hexadecimal]], [[Base64]], or placed directly as a "token" if it meets certain conditions. (Rivest's tokens differ from Lisp tokens in that the former are just for convenience and aesthetics, and treated exactly like other strings, while the latter have specific syntactical meaning.)

Rivest's draft defines a [[Canonical S-expressions|canonical representation]] "for digital signature purposes". It is intended to be compact, easier to parse, and unique for any abstract S-expression. It only allows verbatim strings, and prohibits whitespace as formatting outside strings. Finally there is the "basic transport representation", which is either the canonical form or the same encoded as Base64 and surrounded by [[Bracket|braces]], the latter intended to safely transport a canonically encoded S-expression in a system which might change spacing (e.g. an email system which has 80-character-wide lines and wraps anything longer than that).

This format has not been widely adapted for use outside of SPKI (some of the users being [[GnuPG]], libgcrypt, [[Nettle (cryptographic library)|Nettle]], and [[GNU]] lsh). Rivest's S-expressions web page provides [[C (programming language)|C]] source code for a parser and generator (available under the [[MIT license]]), which could be adapted and embedded into other programs.<ref>{{Cite web|url=http://people.csail.mit.edu/rivest/Sexp.txt|title=SEXP (S-expressions)|website=people.csail.mit.edu|access-date=2023-05-05|archive-date=2023-02-23|archive-url=https://web.archive.org/web/20230223024606/http://people.csail.mit.edu/rivest/Sexp.txt|url-status=dead}}</ref> In addition, there are no restrictions on independently implementing the format.