Re: simple vs. complex parsers

Lieven Marchand <mal@wyrd.be>
18 May 2003 23:50:24 -0400

          From comp.compilers

Related articles
[8 earlier articles]
Re: parsing, was .NET Compiler for Interactive Fiction bobduff@shell01.TheWorld.com (Robert A Duff) (2003-04-20)
Re: simple vs. complex parsers cfc@world.std.com (Chris F Clark) (2003-04-27)
Re: simple vs. complex parsers joachim_d@gmx.de (Joachim Durchholz) (2003-05-05)
Re: simple vs. complex parsers bobduff@shell01.TheWorld.com (Robert A Duff) (2003-05-15)
Re: simple vs. complex parsers cfc@shell01.TheWorld.com (Chris F Clark) (2003-05-18)
Re: simple vs. complex parsers schmitz@essi.fr (Sylvain Schmitz) (2003-05-18)
Re: simple vs. complex parsers mal@wyrd.be (Lieven Marchand) (2003-05-18)
Re: simple vs. complex parsers bs@research.att.com (2003-05-18)
Re: simple vs. complex parsers nmm1@cus.cam.ac.uk (2003-05-23)
Re: simple vs. complex parsers bs@research.att.com (2003-05-23)
Re: simple vs. complex parsers antkaij@mit.jyu.fi (Antti-Juhani Kaijanaho) (2003-05-24)
| List of all articles for this month |

From: Lieven Marchand <mal@wyrd.be>
Newsgroups: comp.compilers
Date: 18 May 2003 23:50:24 -0400
Organization: Only under extreme pressure
References: 03-02-125 03-02-147 03-03-043 03-03-061 03-03-103 03-04-006 03-04-028 03-04-046 03-04-066 03-04-116 03-05-103
Keywords: parse, design
Posted-Date: 18 May 2003 23:50:24 EDT

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.


Post a followup to this message

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