mit-scheme-devel
[Top][All Lists]
Advanced

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

[MIT-Scheme-devel] bootstrap macros, concurrency


From: Taylor R. Campbell
Subject: [MIT-Scheme-devel] bootstrap macros, concurrency
Date: Sat, 22 Apr 2006 05:26:42 +0000
User-agent: IMAIL/1.21; Edwin/3.116; MIT-Scheme/7.7.90.+

Context, for curious listeners:  I'm trying to implement a new macro
alongside some changes deep in the run-time system, and parts of the
run-time system need to use this macro.  I want just to add the macro
definition somewhere in the run-time system and have it be picked up
when compiling the run-time system.  The problem, though, is that any
macros used by the run-time system are inherited solely from the host
compiler, not from the macros defined in the run-time system being
compiled.

As Chris suggested, I tried simply putting the definition of this
macro in a file to whose package definition I added an export of the
macro.  However, this doesn't quite suffice: I need the file with the
macro definition to be syntaxed, and the macro definition processed,
*before* any of the files that use the macro.  Unfortunately, the CREF
package system doesn't support any way to express sequence or
dependency between modules, so I don't know of a way to enforce this.

I also tried adding an (SF-CONDITIONALLY "fluid") -- fluid.scm being
the file with the macro -- to runtime.sf, with the hope that that
might force the desired sequencing, but it had no observable effect.
I realize now that it would need to load fluid.scm first, since the
macro bindings take effect only locally, on the top-level syntactic
environment where they were evaluated, when first syntaxed; one must
evaluate the syntaxed code to get any effect on a top-level normal
(interpreter?) environment.

I'm not sure there is a way around this short of loading fluid.scm
into the host compiler before compiling the run-time system in
runtime.sf after syntaxing it explicitly.  Provisionally, this will
work, but there really ought to be a better way, although I doubt
whether there is without a more controlled macro/module semantics.




reply via email to

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