[gambit-list] Meroon macros

James Long longster at gmail.com
Wed Mar 3 16:15:49 EST 2010


On Wed, Mar 3, 2010 at 2:24 PM, Bradley Lucier <lucier at math.purdue.edu> wrote:
> James:
>
> I'm really impressed with the progress you've made with Meroon in such a
> short time.

Thanks!  I've got some work lined up that I really, really want to use
Black Hole + Meroon for.  So I've got to get it working.

>
> If you want to run with an interpreted Meroon, to debug the Meroon
> sources, say, you can just run the make_meroon script to build
> _meroon.scm and say:

Good to know!

>
> This will not work with Gambit's load procedure, you need to use the
> old-load procedure, as defined in old-load.scm, which simulates a repl,
> it reads each form in _meroon.scm in order and executes it, whether that
> form defines a macro, a function, etc.  When using old-load, gambit
> first expands each form using any macros that have been defined
> previously, which can use any functions that have been defined
> previously.  So this is a layered build system, with very thin
> layers ;-).

The problem is that this is assuming something very specific about how
Gambit expands things.  This makes is very difficult to port it to any
module system which Gambit might adopt.  Because it isn't properly
laid out with clear semantics between phases, there is much work to do
to port it to a good module system which separates phases into
completely disparate environments.

> So one could determine which forms in _meroon.scm depend on which macros
> and on which functions, and group them in files like:
>
> F0: functions that don't depend on any macros
> M0: Macros that use only the functions in F0 (and standard functions) to expand forms
> F1: functions that can be expanded by the macros in M0 (and standard macros)
> M1: Macros that use the functions in F0 and F1 and the macros in M0 to expand forms
> etc.
>
> and then you could load F0, M0, F1, M1, F2, M2, ... in order.

Yes, that would be nice.  I'd rather not learn *that* much about
Meroon, so if anyone wants to do that, I'll buy them a beer.  However,
in the end, maybe I'll do that over time. :)

> So then the question is: What is the role of pre_meroon?

pre_meroon is more than that.  If that's all it was (a plain Meroon
system), I should be able to compile it with `gsc pre_meroon.scm`.
But I can't, because it depends on the strange behavior of loading and
evaluating each form at a time.  So, by loading it that way, and then
using it to compile _meroon.scm, it is also a bootstrapping mechanism,
without which you wouldn't be able to compile Meroon at all, with or
without the postset changes.

See:

% gsc pre_meroon
*** ERROR IN feature-present? -- Unbound variable: *meroon-features*

Looking at the code, it's obvious, because it looks something like this:

(define *meroon-features* '(gambit ...))

(define-macro (if-meroon-feature thing)
  (if (member thing *meroon-features*) ...))

The macro obviously uses a variable that is clearly defined for the
runtime environment.  So, while compiling _meroon.scm, it is actually
using these global variables defined in per_meroon.scm, which is just
odd.

It gets worse.  There is some core global state in Meroon, such as:

(define *class-number* 0)

This variable is referenced by code both in the runtime and macro
phases.  Now, because of the way Meroon is loaded/compiled, this
happens to work and point to the same data.  But I'm not sure I see
much hope anymore of getting Meroon to work with a proper module
system.  The macro environment is (and should be) completely separate
from the global environment in a proper module system.

Basically, there's a macro (CHECK-AND-PROCESS-CLASS-DEFINITION) which
modifies *class-number*, but *class-number* is also modified in
several functions.

I'd like to get this working, but am I wrong in saying that it's going
to be a lot of work?  Are my conclusions valid?  Thanks for being
responsive!

- James



More information about the Gambit-list mailing list