Re: Doing mini-languages in CL

From: Greg Menke (gregm-news_at_toadmail.com)
Date: 02/12/04


Date: 11 Feb 2004 23:10:07 -0500


"Will Hartung" <willh@msoft.com> writes:

> "Greg Menke" <gregm-news@toadmail.com> wrote in message
> news:m3oes5grj5.fsf@europa.pienet...
>
> > 8052 (the one with rom'ed Basic) w/ 32K ram. The output of the
> > mini-language would be assembly- the assembler I have for it is
> > reasonable, I'm quite happy to defer all the instruction coding and
> > address fixup grunt work to it.
>
> 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.

> When you write your own compiler, as long as you have the ability to call
> (greg-compile sexpr), you basically have a macro facility built in to your
> own system, rather than having to "fight" wil CLs.
>
> Your compiler will already take S-exprs, but there's nothing that says those
> S-exprs have to come solely from source code for the microcontroller. You
> can easily do something like this:

<snip sample code, Thanks!>

> I stored the respective function compilers in a hash table (craftily named
> *functions*).
>
> 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.

 
> But for basic stuff, using S-exprs, it's really pretty darn easy to work it
> all out.

Thats what I was going for.
 
> My compiler was pretty simple, pretty limited and relied on nice people like
> me feeding it good code, but when you can essentially create your parse tree
> on the fly and feed it back into the compiler itself, things get pretty easy
> pretty darn fast, and you find you won't necessarily need macros. Now, if
> you want macros in your mini-language, that's a different animal entirely.
>
> Luck.
>
> Regards,
>
> Will Hartung
> (willh@msoft.com)

Thanks! I think those are the hints I needed- next I'll see if I can
do something.

Gregm



Relevant Pages

  • Re: Reflections on a classic Lisp Paper
    ... lisp dialects. ... user-defined special forms - Macros, Fexprs, and Nlambda. ... compilable because the compiler just couldn't do it. ...
    (comp.lang.lisp)
  • Re: Cpp Considered Harmful
    ... > However, in either case, assertions are invaluable in making certain ... because we now have our own cpp ... > macros, we can use several different compilers and have our system ... > built into the compiler. ...
    (comp.lang.cpp)
  • Re: Doing mini-languages in CL
    ... > Thats it in a nutshell. ... I think the detail to note is that the Macro facility is a Compiler ... simply put you may well be able to leverage CL macros in building your ...
    (comp.lang.lisp)
  • Re: Why doesnt Lisp automatically differentiate functions and macros?
    ... what stops a Lisp machine from figuring automatically which ... small subset of things macros can do that you are thinking is all they can ... This requires the compiler to know how to do things. ... things that the compiler writer didn't think to, ...
    (comp.lang.lisp)
  • Re: Doing mini-languages in CL
    ... "Will Hartung" writes: ... That's similar to what I do except I use macroexpand-1 because some ... macros are easier to deal with at intermediate stages of expansion. ... of LET and TAGBODY. ...
    (comp.lang.lisp)