Re: Doing mini-languages in CL

From: Will Hartung (willh_at_msoft.com)
Date: 02/12/04 

Date: Thu, 12 Feb 2004 10:32:16 -0800

"Greg Menke" <gregm-news@toadmail.com> wrote in message
news:m3r7x1os4g.fsf@europa.pienet...
> "Will Hartung" <willh@msoft.com> writes:

> > So, simply put the goal is to write a pure compiler, not an emulator or
a
> > simulator or anything like that. Rather, you put in "GregLisp", and out
come
> > 8052 Assembly to be assembled, hexified, downloaded, burnt, plugged in
and
> > tested just like any other bit of 8052 Assembly.
>
> Thats it in a nutshell. From that perspective, my question was how to
> arrange the symbol names for the functions "GregLisp" implements.
>
>
> > If your primary goal in using CL is mostly for its macro facility, I
would
> > stop right there.
>
> I was more hoping to leverage the reader, with the ability to use
> macros as something thats potentially useful- but which I probably
> don't understand how to arrange at the moment.

Yeah, I think the detail to note is that the Macro facility is a Compiler
attribute, not a Reader attribute. The reader doesn't do macro expansion,
the compiler does. Grokking that detail early helps set expectations. So,
simply put you may well be able to leverage CL macros in building your
compiler, but the language your compiler will be compiling will probably not
be able to directly leverage CL macros (but could well have its own).

Hmm..

Actually you could do something sick like this in your compiler:

(defun greg-compiler (form)
  (cond
   ((consp form) (compile-function-or-macro form))
    ...)))

(defun compile-function-or-macro (form)
  (let ((macro-symbol (first form)))
    (cond ((eq macro-symbol 'defmacro (eval form))) ;; defining a new macro,
let CL do the work
          ((macro-function macro-symbol) (greg-compiler (macroexpand form)))
;; compile the expanded form
          (t (compile-function form))))) ;; something I can actually
understand.

This let's you use the stock CL defmacro facility on your s-exprs, but the
real problem is that you'll end up "polluting" the namespace of your CL
image with macros for your language. You'll probably have other package
issues and potential conflicts, but you can work through those I'm
bettering. So, in that sense, you're using the CL macros as sort of a crude
"pre-processor". But shrewd package management can keep that from being a
horrible issue, and it gives your language macros "for free". And you
thought getting #xFF was cool!

> > If you rely on Symbols and property lists (something I didn't think
about
> > being more in Java mode that Lisp mode), then you associate the compiler
> > function directly with the symbol rather than building up a table like I
> > did. Whatever floats your boat.
>
> I get the impression that figuring this out will be a good education
> for me on how Lisp handles symbols.

Symbols are one of those anachronisms of CL. They're amazingly powerful
objects that were overloaded and used for "everything" back in the day. When
folks think that CL doesn't have any data structures of note, it's because a
lot of stuff was done with Symbols and their properties (and lists).

But when you come to CL from other lanaguages, and look for things like
hashtables et al, you then overlook Symbols and all they provide simply
because other lanaguages don't have anything like them. They're just Yet
Another tool that CL provides to be leveraged as appropriate and its always
good to at least know what tools are IN the toolbox, if not necessarily
knowing exactly how to USE them.

Regards,

Will Hartung
(willh@msoft.com)