short for "S-Expression" [http://en.wikipedia.org/wiki/S-expression] (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

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

----

Comparing Tcl lists and SEXPs may be instructive in explaining some fundamental differences between [Tcl and LISP]. The following is a SEXP
  (abc (de #6667#) "ghi jkl")
and this is the corresponding Tcl list
  abc {de \x66\x67} "ghi jkl"
Some useful observations are:
   1. Both allow several equivalent ways of encoding the same information, e.g. the #6667# / \x66\x67 could alternatively have been written fg. SEXPs offers about twice as many forms as Tcl lists do, however. (This is typical. In comparison to the radical simplicity of Tcl, [LISP] is a language suffering from severe featuritis.)
   2. In the SEXP, there is parenthesis around the outer list, whereas there is no such thing in the Tcl list. This reflects the fact that a SEXP inherently has a type (the example is a list), whereas Tcl 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 Tcl-native encoding of a list of SEXPs as above could be as a list where even elements are types and the odd ones the corresponding values. 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 every non-list has a type tag, even though one normally omits it.)

----
[dcd] is sceptical of Lars' scepticism. I'll offer these tcl results:
  % string range [split {a b c}] 0 1
  a
  % string  range [split {{a} {b} {c}}] 0 1
  {{
That said, I chose tinytcl over SIOD for an embedded application because of it's untyped simplicity and the fact that it would require less CS background for any future maintainer. Aesthetically, though, lisp and the SDSI SEXP's are far more appealing. In fact, in true lisp 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.

         SIOD: http://www.cs.indiana.edu/scheme-repository/imp/siod.html
----
[Category Glossary] | [Category Internet]