[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: on bootstrapping: introducing Mes

From: Mike Bushroe
Subject: Re: on bootstrapping: introducing Mes
Date: Mon, 20 Jun 2016 10:47:42 -0700

I have been quietly lurking for quite some time now, but this stirs up old
memories. Back in college we built a compile for a local language called
'y' which was very similar to C, and the compiler was written in 'yacc',
yet another compiler compiler.

It sounds like you are moving to a two layer approach, a base layer in C
that would have to be compiler for any new host that would interpret a
minimal subset of LISP, and then a full LISP interpreter that would support
most or all of the language. If this is really the case, you should
consider what you want/need in the lower level, and what you want to push
up into the stripped LISP layer. Remember that no matter how small the
lower level C core is, it will still need to be cross compiled to run on
any other platform. Since gcc it easily available and good at cross
compiling that is not a major problem. But it does mean that keeping in
very small and limited may not buy you very much. So implementing macros in
the LISP layer should be compared with implementing them in C, if that
proves easier.

  Another suggestion if you want to have this easily portable would be to
add a third component, the OS/hardware interface. If you have one small C
file to cross compile, an unchanging covering layer of LISP to handle most
of the more complex parts of the interpreter, and an interface descriptor
file then you have the advantage that the core C code and the LISP upper
layer code never change (accept for cross-compiling the C for a new
machine) then the only file that needs changing is the OS/hardware file.
And if you create the format for that to be human readable text that
matched a text description of the task to be performed and then the text,
code, shell instructions needed to perform that code it would be fairly
easy for anyone else to modify the package to work in any custom
application that they had.

  As for the scary part of define-syntax, once you have a tokenizer written
from the getc, ungetc routines, it is fairly straight forward to use the
tokens returned (variable names, numbers, language commands, math/logic
operators, and block/structure symbols) and build a state machine that
walks through each syntax sequence starting with a new code line and
sending out assemble code lines to compile or executing steps in an
interpreter. Using recursion for numeric expressions and nested block
structures. Yes, scary at first but it is surprising how quickly language
breaks down into recursive syntax structures.

 Regardless of how you proceed from here, good luck and it sounds like you
are having fun!


On Sun, Jun 19, 2016 at 4:08 AM, Jan Nieuwenhuizen <address@hidden> wrote:

> Hi,
> I have a minimal LISP-1.5-resembling interpreter in C that now can
> also interpret itself
> It was inspired by the seemingly often ignored bootstrapping question
> made so painfully visible by GuixSD and by OriansJ with their self
> hosting hex assembler project.
> As a next step after a hex assembler I was thinking of getting Scheme up
> and running and use that to create a tiny C compiler, probably using
> PEG.  For that I think we need define-syntax, which I had a peek at and
> still scares the all-sorts-of-things out of me :-)
> I searched for minimal Lisp/Scheme to get that going and found an
> article called the Maxwell Equations of Software 1) with a pointer to
> the 1962 LISP 1.5 paper by John McCarthy 2).
> First I `implemented' Mes/LISP-1.5: the bottom half of page 13 and the
> necessary helper procedures defined on pages 8-12 using Guile, removing
> all but the primitives needed to run LISP-1.5/Mes (I think): car, cdr,
> cond, cons, define, eq?, '()/nil, null?, pair? and quote.  I cheated
> with read, and with display and newline for debugging.
> Then I translated the program into C and got rid of read by using
> getchar/ungetchar.
> It's been great fun and now I'm kind of stuck a bit at the point of
> implementing macros.  I have a simplistic version in C but want to
> remove that again --I like the idea of having the absolute minimal LISP
> interpreter in C-- and only introduce macros after having bootstrapped
> into the LISP/Mes domain.
> Greetings,
> Jan
> 1)
> 2)
> 3)
> --
> Jan Nieuwenhuizen <address@hidden> | GNU LilyPond
> Freelance IT | Avatar®

"Creativity is intelligence having fun." — Albert Einstein

reply via email to

[Prev in Thread] Current Thread [Next in Thread]