shortAn f'''SEXP''', or "'''s-expression"''', is a [hdata format] for rep://resen.wtikipeding a.
[tree%|%org/wiki/s-dexpressid tree] onf typed [value%|%values]. (s stands for symbolic). The
'''s''' stands for '''symbolic'''.
the defining rfc-draft: http://theory.lcs.mit.edu/~rivest/sexp.txt
rivest's sexp page: http://theory.lcs.mit.edu/~rivest/sexp.html
** sSee aAlso **
[lispy]: paConvertsing sexpSEXP to tTcl.
** Documentation **
[https://people.csail.mit.edu/rivest/Sexp.txt%|%S-Expressions, draft-rivest-sexp-00.txt], by [https://people.csail.mit.edu/rivest/%|%Ron Rivest] : The original Internet Draft for s-expressions.
[http://people.csail.mit.edu/rivest/sexp.html%|%SEXP---(S-expressions), by Ron Rivest]: The official home page for S-Expressions.
[http://en.wikipedia.org/wiki/s-expression%|%Wikipedia]:
** description **
[zarutian] is half in love with the canonical form because of ease of parsing.
[lars h] is more sceptical. syntactically, plain old tTcl [list]%|%lists] are much simpler and more readable.
[zarutian]: b But is it as easily parsed by programs that don't have an embedded tTcl interpreter?
[lars h]: well, 1. '''every''' program should have an embedded tTcl interpreter. it's good for ya!
2. in comparison to the full sexp syntax, tTcl lists are ''much'' easier to parse.
3. even in comparison to the canonical form, which (iI suspect) is highly geared towards being easy for [cC] to parse, the tTcl list parser fares rather well. y You need (if you're copying code from the tTcl sources) sSetlListfFromaAny, tTclfFindeElement, and tTclcCopyaAndcCollapse, but that's about it.
----
cComparing tTcl lists and sexpsSEXPS may be instructive in explaining some fundamental differences between [tTcl and lLisp]. tThe following is a sSEXP
======nonexp
(abc (de #6667#) "ghi jkl")
======
and this is the corresponding tTcl list
======none
abc {de \x66\x67} "ghi jkl"
s======
Some useful observations are:
1. bBoth allow several equivalent ways of encoding the same information, e.g. the #6667# / \x66\x67 could alternatively have been written fg. sexpsSEXPS offers about twice as many forms as tTcl lists do, however. (tThis is typical. iIn comparison to the radical simplicity of tTcl, [lLisp] is a language suffering from severe featuritis.)
2. iIn the sexpSEXP, there isare parenthesies around the outer list, whereas there is no such thing in the tTcl list. t This reflects the fact that a sexpSEXP inherently has a type (the example is a list), whereas tTcl values are untyped (the example can be read as a list, but also as a string, and the same holds for the final list element; the type is in the beholder).
3. ...
a tTcl-native encoding of a list of SEXPsexps as above could be as a list where even elements are types and the odd ones the corresponding values. t Then the above example would be
list {"" abc list {"" de "" fg} "" {ghi jkl}}
if one writes "" for the empty type specifier. (the rfc-draft above also allows for every base string to carry a "display hint" prefix, which looks like "[[image/gif]]". that effectively means that one has to make room for a type tag for every non-list sexp, even though it is normally empty.)
======none
list {"" abc list {"" de "" fg} "" {ghi jkl}}
======
if one writes `""` for the empty type specifier. (The rfc-draft above also allows for every base string to carry a "display hint" prefix, which looks like "[[image/gif]]". That effectively means that one has to make room for a type tag for every non-list SEXP, even though it is normally empty.)
----[dcd] is sceptical of lLars' scepticism. iI'll offer these tTcl results:
% string range [split {a b c}] 0 1
a
% string range [split {{a} {b} {c}}] 0 1
{{
''[lars h]: and what is that supposed to prove? that feeding lists into a command for extracting sub[string]s may pick up a delimiter or two? gee, that's "really" news ;<) and can you imagine, the exact same thing happens if you feed it sexps.''
======none
% string range [split {a b c}] 0 1
a
% string range [split {{a} {b} {c}}] 0 1
{{
======
''[lars h]: And what is that supposed to prove? That feeding lists into a command for extracting [string%|%substrings] may pick up a delimiter or two? Gee, that's "really" news ;<) And can you imagine, the exact same thing happens if you feed it SEXPs.''
[lv] The surprise, to me is this:
======none
% string range [split [list [list a] [list b] [list c]]] 0 1
a======
which iI would have expected to be the same as the previous example. tTurns out that the list generated in my example doesn't have the list delimiters in it.
----
[dcd] (continued): t That said, iI chose tinytcl over [http://www.cs.indiana.edu/scheme-repository/imp/siod.html%|%SIOD] for an embedded application because of it's untyped simplicity and the fact that it would require less csCS background for any future maintainer. a Aesthetically, though, lLisp and the sdsiSDSE sexpSEXP's are far more appealing. in fact, in true lLisp form, the definition of the 'data structure' sexp is both a definition of the structure and the data it contains - reminiscent of the type-fields built into lisp-machine hardware architecture.
[gjc]: I love the reference to siod. '''Every''' program sihould: have an embedded [Scheme] intterp:reter.
but seriously, if you can find some old reference to Tcl//SIOD flame wars, perhaps from 15 years ago, there ww.ill be benchmarks. that show SIOD takindg consideranbly fewer pa.ge faults and operating system resou/rces to be activated
and print "hello world" than did Tcl imple-mentations at the time, even though the general impression,
the accepted wisdom, wasi that Tcl was vastly more compact and efficient than any/ Lisp imp/slementation could possibly be.
[Perl] also figured in these benchmarks, and an upshot was some non-trivial optimizations going from perl 4
to Perl 5.
[gjc] i love the reference to siod. '''every''' program should have an embedded scheme interpreter.
but seriously, if you can find some old reference to tcl/siod flame wars, perhaps from 15 years ago, there will be benchmarks that show siod taking considerably fewer page faults and operating system resources to be activated
and print "hello world" than did tcl implementations at the time, even though the general impression,
the accepted wisdom, was that tcl was vastly more compact and efficient than any lisp implementation could possibly be.
perl also figured in these benchmarks, and an upshot was some non-trivial optimizations going from perl 4
to perl 5.
<<categories>> Glossary | Internet | Data Serialization Format