On Sun, Feb 10, 2008 at 06:24:40PM -0800, Andrew Lentvorski wrote:
And I will assert that you are *wrong*.
Lisp (as s-expressions) is particularly *annoying* to parse. Parsing the
following expression is a PITA:
('() 1 2 '(2 . 3) . 4)
In what way? The lisp reader is amazingly simple. It's a trivial
recursive descent parser.
or perhaps if you want to watch your stack blow:
'((((((((('())))))))))
Sure, these are contrived pathological cases, but they tend to be *real*
cases after a macroexpander gets done with code.
They aren't pathological at all, and no deeper than the nesting depth you
might find in any other language that has structure. I'm not sure what
kind of architecture you would be running lisp on that would have a problem
with a few dozen stack levels. I just created an expression similar to
yours with 5000 open parens and then matching closing parens. None my lisp
systems are bothered by it in any way.
Looking through the reader for SBCL, a good portion of the code is the
state machine that matches individual tokens, something you would find in
any language parser. Then, a good chunk parses numbers. The main 'read'
that reads through tokens and groups things into lists is just a dozen or
so lines of code.
Dave
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
