On Wed, Mar 3, 2010 at 2:24 PM, Bradley Lucier lucier@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