Norvig and Pitman's "Tutorial on Good Lisp Programming Style" mentions
that some of the things Lisp is good for is:
Source-to-source or data-to-data transformation
Compilers and other translators
Problem-specific languages
I was wondering what was meant by the "source-to-source" part, in
other words is it just talking about embedded languages in prefix form
or actually more like transforming one "non-Lisp" flat file format
into another. I've only seen example code of the first kind and would
like to see examples of the other kind.
······@bellsouth.net (Ralph Richard Cook) writes:
> Norvig and Pitman's "Tutorial on Good Lisp Programming Style" mentions
> that some of the things Lisp is good for is:
> Source-to-source or data-to-data transformation
> Compilers and other translators
> Problem-specific languages
>
> I was wondering what was meant by the "source-to-source" part, in
> other words is it just talking about embedded languages in prefix form
> or actually more like transforming one "non-Lisp" flat file format
> into another. I've only seen example code of the first kind and would
> like to see examples of the other kind.
It means that you can easily, without the addition of a zillion
libraries, do things like this (for some imaginary user-defined
function ADD, which presumably has the same general nature as the
built-in +, about which you are forbidden to write compiler macros
since the system is assumed to have its own built-in ones that you
shouldn't clobber):
(define-compiler-macro add (&whole form &rest args) ;no, i didn't test this
(let* ((changed nil)
(transformed-args
(mapcan #'(lambda (arg)
(cond ((and (consp arg) (eq (first arg) 'add))
(setq changed t)
(copy-list (rest arg)))
(t (list arg))))
args)))
(if (not changed)
form
`(add ,@transformed-args))))
Put another way, the language itself contains in its basic datastructures
the ability to manipulate its own programs. This makes it very easy for
programs to analyze and optimize themselves in interesting ways.
In general, though, in response to the second half of your question,
what supports other languages is the ability to easily write parsers,
and then to embed them in the Lisp parser and printer. For example,
you might write a parser for an infix language and embed it in Lisp so
that
(defun foo (x y) #[ x+y ])
turned into some parsed representation of another language that was
executable by Lisp, and you could further modify the printer and/or
the pretty-printer to print the result back out the same way so that
you didn't have to see the parsed form if it didn't look pretty in CL.
For example, if you look at XML or FrameMaker MIF files or RTF files or
any of a number of plaintext representations of structure, it can be
made to interact and be transformed very gracefully with CL. I think
there are some examples of this in AllegroServe, if you're looking for
large, publicly available sources to peruse.
The Macsyma language was another example. It used (and in some corners
of the world where it's still kicking still uses) an infix representation
that had a standard casting into lisp lists, so that some Macsyma libraries
manipulate source trees in the Macsyma language while others are written
in Lisp and manipulate the internal lisp parsed structure. I'm really sad
that Dylan did not spend more time studying this symbiosis because it seemed
to work fine for Macsyma even though the Dylan people quickly declared it
unworkable to maintain parallel/interchangeable Lisp and infix forms.
Kent M Pitman <······@world.std.com> wrote:
>It means that you can easily...
Thanks for the reply, and I also wanted to say thank you for all the
other thoughtful, non-flaming answers you've given to newbies in the
past. Many's the time I've searched this newsgroup and seen you write
an answer to a programming question that I've printed out and added to
my Lisp references.