Meroon for Scheme48
I tried to port the Meroon object system to Scheme48. This turned out to be trickier than I thought.
Meroon is an efficient, CLOS-like object system by Christian Queinnec. It is one of the two standard object systems for Scheme, next to TinyCLOS. I was interested in playing around with it. So I looked into how it can be ported to a new implementation.
The system consists of a number of source files. To use it, an
implementation-specific initialization file is loaded. Then, loading
the file meroon.scm should take care of loading the rest
of Meroon. So the whole initialization process is based
on load.
Most implementation-specific initialization files are restricted to
providing two kinds of macros, and a variable describing the supported
features. The macros define-meroon-macro
and define-internal-meroon-macro are used by Meroon as a
portable macro system. They both work just
like defmacro
in Common Lisp (and indeed, I could not find out where the two would
differ). The variable *meroon-features* is
a plist
describing the features supported by the current implementation. Since
I didn’t want to supported any further features at first, I
used '(scheme48 "1.2") as a value.
It is nontrivial to come up with a definition of
defmacro for Scheme48. Indeed, there is an inherent
incompatibility, which eventually proved to be my demise. But first
things first. Scheme48 does not provide defmacro,
preferring the cleaner explicit
renaming as the macro system of choice. Interestingly enough, SLIB does
provide a working defmacro for Scheme48 which uses
eval and interaction-environment from R5RS.
This allows the implementation to work only in the REPL, not if
provided via a real module. Pity.
Though explicit renaming and defmacro might
superficially look similar, there is a fundamental difference. The
code evaluated in the body of the macros use different environments.
While defmacro uses the same environment as the code
which uses it, explicit renaming macros use a different storey in the
syntactic tower. This is intentional, as the two stages in evaluating
code are indeed different. Among variables which Meroon expects in the
syntactic environment is the already
mentioned *meroon-features* for conditional compilation,
but also other things.
To solve this problem, Meroon needs to be separated more cleanly
between the different stages. I would assume this is not really a
problem—for *meroon-features*, a separate module which
can be opened normally and for-syntax is sufficient. Ideally, the
whole setup using load should be replaced by module
definitions.
I don’t have the time for this. Maybe, if someone reads this, he can pick up where I left off. Good luck.
