I have a project which contains a bunch of small programs tied together using bash scripts, as per the Unix philosophy. Their exchange format originally looked like this:
cut -d ' '
cut -d ':'
meta1a:meta1b:meta1c:meta 1 d\tAST1
meta2a:meta2b:meta2c:meta 2 d\tAST2
(echo '(("foo1" "bar1" "baz1" "quux 1") ast1)'
echo '(("foo2" "bar2" "baz2" "quux 2") ast2)') | sexpr 'caar'
You might give Common Lisp a try.
Straightforward use of stdio with minimal boilerplate, since that's where my programs read/write their data
(loop for (attributes ast) = (safe-read) do (print ...)
safe-readshould disable execution of code at read-time. There is at least one implementation. Don't
evalyour AST directly unless you perfectly know what's in there.
Easily callable from shell scripts or provide a very compelling alternative to bash's process invocation and pipelining
In the same spirit as
java -jar ..., you can launch your Common Lisp executable, e.g.
sbcl, with a script in argument:
sbcl --load file.lisp. You can even dump a core or an executable core of your application with everything preloaded (
cl-launch which does the above automatically, and portably, and generates shell scripts and/or makes executable programs from your code.
Streaming I/O if possible; ie. I'd rather work with one AST at a time rather than consuming the whole input looking for a closing )
If the whole input stream starts with a
read will read up-to the closing
) character, but in practice this is rarely done: source code in Common Lisp is not enclosed in one pair of parenthesis per-file, but as a sequence of forms. If your stream produces not one but many s-exps, the reader will read them one at a time.
Fast and lightweight, especially if it's being invoked a few times; each AST is only a few KB, but they can add up to hundreds of MB
Fast it will be, especially if you save a core. Lightweight, well, it is well-known that lisp images can take some disk space (e.g. 46MB), but this is rarely an issue. Why is is important? Maybe you have another definition about what lightweight means, because this is unrelated to the size of the AST you will be parsing. There should be no problem reading those AST, though.
Should work on Linux at least; cross-platform would be nice
See Wikipedia. For example, Clozure CL (CCL) runs on Mac OS X, FreeBSD, Linux, Solaris and Windows, 32/64 bits.