short for "Ss-Eexpression" [http://en.wikipedia.org/wiki/Ss-expression] (Ss stands for symbolic).
Tthe defining RFCrfc-draft: http://theory.lcs.mit.edu/~rivest/sexp.txt
Rrivest's SEXPsexp page: http://theory.lcs.mit.edu/~rivest/sexp.html
[Zarutian] is half in love with the canonical form because of ease of parsing.
[Lars** H] is more sceptical. Syntactically, plain old Tcl [list]s are much simpler and more readable.**
[Zarutlianspy]: but is it pars easilyng parsed by xprograms that don't have an embedded Ttcl interpreter?
[Lars H]: Well,
1. '''Every''' program should have an embedded Tcl interpreter. It's good for ya!
2. In comparison to the full SEXP syntax, Tcl lists are ''much'' easier to parse.
3. Even in comparison to the canonical form, which (I suspect) is highly geared towards being easy for [C] to parse, the Tcl list parser fares rather well. You need (if you're copying code from the Tcl sources) SetListFromAny, TclFindElement, and TclCopyAndCollapse, but that's about it.
** description **
[zarutian] is half in love with the canonical form because of ease of parsing.
[lars h] is more sceptical. syntactically, plain old tcl [list]s are much simpler and more readable.
[zarutian]: but is it as easily parsed by programs that don't have an embedded tcl interpreter?
[lars h]: well,
1. '''every''' program should have an embedded tcl interpreter. it's good for ya!
2. in comparison to the full sexp syntax, tcl lists are ''much'' easier to parse.
3. even in comparison to the canonical form, which (i suspect) is highly geared towards being easy for [c] to parse, the tcl list parser fares rather well. you need (if you're copying code from the tcl sources) setlistfromany, tclfindelement, and tclcopyandcollapse, but that's about it.
----
Ccomparing Ttcl lists and SEXPsexps may be instructive in explaining some fundamental differences between [Ttcl and LISPlisp]. Tthe following is a SEXPsexp
(abc (de #6667#) "ghi jkl")and this is the corresponding Ttcl list
abc {de \x66\x67} "ghi jkl"Ssome 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. SEXPsexps offers about twice as many forms as Ttcl lists do, however. (Tthis is typical. Iin comparison to the radical simplicity of Ttcl, [LISPlisp] is a language suffering from severe featuritis.)
2. Iin the SEXPsexp, there is parenthesis around the outer list, whereas there is no such thing in the Ttcl list. Tthis 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. ...
Aa 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. Tthen the above example would be
list {"" abc list {"" de "" fg} "" {ghi jkl}}if one writes "" for the empty type specifier. (Tthe RFCrfc-draft above also allows for every base string to carry a "display hint" prefix, which looks like "[[image/gif]]". Tthat effectively means that one has to make room for a type tag for every non-list SEXPsexp, even though it is normally empty.)
----[dcd] is sceptical of Llars' scepticism. Ii'll offer these tcl results:
% string range [split {a b c}] 0 1
a
% string range [split {{a} {b} {c}}] 0 1
{{''[Llars Hh]: Aand what is that supposed to prove? Tthat feeding lists into a command for extracting sub[string]s may pick up a delimiter or two? Ggee, that's "really" news ;<) Aand can you imagine, the exact same thing happens if you feed it SEXPsexps.''
[LVlv] Tthe surprise, to me is this:
% 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): Tthat said, Ii chose tinytcl over SIODsiod for an embedded application because of it's untyped simplicity and the fact that it would require less CScs background for any future maintainer. Aaesthetically, though, lisp and the SDSIsdsi SEXPsexp's are far more appealing. Iin fact, in true lisp form, the definition of the 'data structure' SEXPsexp is both a definition of the structure and the data it contains - reminiscent of the type-fields built into lisp-machine hardware architecture.
SIODsiod: http://www.cs.indiana.edu/scheme-repository/imp/siod.html
[gjc] Ii love the reference to SIODsiod. '''Eevery''' program should have an embedded scheme interpreter.
Bbut seriously, if you can find some old reference to TCLtcl/SIODsiod flame wars, perhaps from 15 years ago, there will be benchmarks that show SIODsiod taking considerably fewer page faults and operating system resources to be activated
and print "hello world" than did TCLtcl implementations at the time, even though the general impression,
the accepted wisdom, was that TCLtcl was vastly more compact and efficient than any Llisp implementation could possibly be.
Pperl also figured in these benchmarks, and an upshot was some non-trivial optimizations going from Pperl 4
to Pperl 5.
<<categories>> Gglossary | Iinternet | Ddata Sserialization Fformat