Re: simple vs. complex parsers

Robert A Duff <bobduff@shell01.TheWorld.com> writes:


> Lisp suffers from the many-dialect problem. But that's a somewhat
> different issue, I think. Each of those dialects has a *very* simple
> syntax, compared to most languages.


Yes and no. To make this concrete let us take ANSI Common Lisp. In a
real sense, it has *no* syntax since the language is specified to take
a sequence of Lisp objects as its source representation. This
representation is built from the text source file using the Lisp
reader with its full power. So even at read time a programmer has the
whole lisp language at his disposal.


A small rather obfuscated example is


CL-USER 1 > #.(list (intern (concatenate 'string "DE" "FUN")) '|Foo Bar|
                                        nil (list (find-symbol "+" "COMMON-LISP") 1 2))
|Foo Bar|


CL-USER 2 > (\F\o\o\ \B\a\r)
3


which is a rather roundabout way to do (defun |Foo Bar| (+ 1 2)).


#. is a read time macro that tells the reader to evaluate the
following code and substitute that in the token stream. Any character
can be made to be such a macro (rather like the active characters of
TeX). A more useful example would be to redefine the " character so
that instead of building a constant string as it does by default it
tries to look up the string in an internationalisation database (this
example is due to Erann Gat in comp.lang.lisp). In theory, you could
make a Lisp compiler compile Pascal by making enough characters active
to parse the Pascal program and translate it into Lisp code.


For parsing of Lisp source, you need something equivalent to the Lisp
reader. The difference between Lisp and some other languages isn't
necessarily the simplicity of syntax but that a parser is included in
the standard language.

Return to the comp.compilers page.
Search the comp.compilers archives again.