Re: compiling syntax and macro

[Jost Boekemeier <jostobfe at linux dot zrz dot TU-Berlin dot DE>]

Keisuke Nishida <kxn30@po.cwru.edu> writes:

> Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE> writes:
> 
> > > So the rest of the major tasks about compiling is module support.
> > 
> > What do you need?
> 
> I need to let the compiler know what environment to use.
> A module defines the current environment (or top-level, etc), right?

I think you can use the specifier that %make-extents returns.

[...]
            e             x             l
identifier ---> variable ---> location ---> value

An environment @math{e} is the mapping of identifiers to variables. It
is not a first-class value.  In the current module system variables
are first-class values and the module system sits on top of them.  I
remove first-class variables and make the extent map @math{x} a
first-class value.  To support @code {set!} a location map @math{l}
maps the location to the actual value.

[...]

@deffn Primitive %make-extents extent-name ...
Create a new environment, for every @var {extent-name} an extent and
bind it to the name @var {extent-name} in the environment.  A
specifier is returned.
@end deffn



> Oh, really?  Hmm, I think I should wait.

Nonono.  Just go ahead.  The reason why I choose to use extents
instead of environments is that one

a) can build GOOPS ontop of it
b) can build a prototype based OO system (like Cecil's) ontop of it
c) gets fluid-define, fluid-let, fluid-set!, fluid-ref for free
d) can build any module system ontop of it
e) can build SRFI-9 ontop of it.

Ah, and the problems we've had with generic's: forget them, they don't
exist anymore (the problems, not the generics, of course :>).


Jost