short for "s-expression" [1] (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

see also  edit

lispy

parsing sexp to tcl

description  edit

zarutian is half in love with the canonical form because of ease of parsing.

lars h is more sceptical. syntactically, plain old tcl lists 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 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 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
  {{

lars h: and what is that supposed to prove? that feeding lists into a command for extracting 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:

   % string range [split [list [list a] [list b] [list c]]] 0 1

a

which i would have expected to be the same as the previous example. turns out that the list generated in my example doesn't have the list delimiters in it.

---

dcd (continued): 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

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

---