Re: comments on new-model.txt

[Marius Vollmer]

Lynn Winebarger <address@hidden> writes:

> > Can you give example code that illustrates their use?
>
>      Ok, I'll make up some incredibly bad notation
>
> (exporting-lambda () 
>    (define-exportable foo  'whatever)
>    (define-exportable-syntax (lambda (x) (syntax-case x () ((_ f ...) (syntax 
> 'xyzzy)))))
>    ....)
>
>        If we have extlocs, this can be just a plain lambda that
> happens to let import take references to some of its variables.
> Then we can use the keyword "module" instead.

Is this related to the 'module' feature of recent versions of Dybvig's
syntax-case implementation?  If so, I think that it is implemented
solely with renaming of identifiers and needs no support from the
interpreter.  Also, I think that the syntax-case modules are less
powerful than ours since their semantics are fixed while ours can be
cleanly extended.

>      Part of the disagreement is that I don't think we should
> "evaluate in" modules. Partly this is a terminology issue:  I think
> "module" should be reserved for separately compilable units of
> code that won't be invisibly dependent on whatever code happens
> to be currently loaded ("invisibly" is because imports are clearly
> visible to the module-using programmer, so are not prohibited).

You can use our current modules that way, but the new model is not
restricted to such a use.  The concept of "evaluating in a module" is
still there, even when modules are sealed compilation units.  It's not
strictly "evaluating" in a module, but the module is part of the
compile time environment and determines the meaning of identifiers
just as with our current situation, where modules are part of the
run-time environment.

>     We should have some other terminology to describe other types of
> namespaces.  Being able to import/export variables is just one knob
> on a namespace/environment/whatever.

Yes, and that's why there are little module system specifics in the
new model.  You can implement a wide variety of modules that are
compatible with it.

>     And then there's Dirk's view of modules as parameterizable to
> get a handle on too.

They are possible as well.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405