Re: Dynamic Language (grammar)

Martin Rodgers <mcr@wildcard.demon.co.uk>
5 Aug 2000 21:35:03 -0400

          From comp.compilers

Related articles
Dynamic Language (grammar) pohanl@my-deja.com (2000-07-31)
Re: Dynamic Language (grammar) mcr@demon.co.uk (Martin Rodgers) (2000-08-04)
Re: Dynamic Language (grammar) jimbo@radiks.net (2000-08-04)
Re: Dynamic Language (grammar) mcr@wildcard.demon.co.uk (Martin Rodgers) (2000-08-05)
Re: Dynamic Language (grammar) mcr@wildcard.demon.co.uk (Martin Rodgers) (2000-08-05)
Re: Dynamic Language (grammar) mcr@wildcard.demon.co.uk (Martin Rodgers) (2000-08-10)
Re: Dynamic Language (grammar) koontz@ariolimax.com (David G. Koontz) (2000-08-10)
Re: Dynamic Language (grammar) mcr@wildcard.demon.co.uk (Martin Rodgers) (2000-08-14)
| List of all articles for this month |

From: Martin Rodgers <mcr@wildcard.demon.co.uk>
Newsgroups: comp.compilers
Date: 5 Aug 2000 21:35:03 -0400
Organization: The Wildcard Killer Butterfly Breeding Ground
References: 00-07-094 00-08-007
Keywords: syntax, comment

> Note how this is done in Lisp and Forth.
> http://www-mitpress.mit.edu/sicp/
> http://www.forth.com/Content/History/History1.htm
> --
> [Also see tcl, same idea. -John]


By not distinguishing between code that implements Forth and code that
the programmer writes (adds to the language), Forth typically achieves
meta-circularity with greater success than any other language I know.
This is also done with great simplicity, and a single pass compiler.
It's an excellent language for exploring basic compiler theory, and
even some of the more advanced ideas (native code, JIT, etc). I doubt
there's anything that can't be - or hasn't been - tried in Forth.


As I understand it, Tcl manipulates language via string processing,
which is a very messy representation. As Alan Perlis put it,


"The string is a stark data structure and everywhere it is passed
there is much duplication of process. It is a perfect vehicle for
hiding information."


Lisp processes code by not only conflating code with data, but by
using trees. A compiler may be described as a program which takes a
representation of a program, written in one language, and translats it
into another representation, written in another language.


The representation may be a string, but trees are also possible. Lisp
and Prolog use trees internally, and string representations of the
trees externally. Tree rewritting is well known. Lisp programmers have
been doing it for 40 years. Today we also see tree rewritting applied
to XML, via languages such as XSL. They too conflate code with data,
but less successfully. Perhaps this is because they're not intended
more for non-programmers? Perhaps their designers are less familiar
with tree-writing languages (remember, the domain of Lisp is language
itself) than Lisp designers, who have 40 years of experience?


I've only been using Lisp for about 15 years, but I frequently find
other programmers telling me that things that I do with great ease
every day are hard. So I know what Alan Perlis meant when he said,


"A language that doesn't affect the way you think about programming,
is not worth knowing."
--
[Alan said lots of stuff, much of it contradictory. (He was my thesis
advisor.) TCL actually does a rather good job of having a syntax that
you can extend, even though everything is a string. It's worth a look.
-John]


Post a followup to this message

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