comments on new-model.txt

[Lynn Winebarger <owinebar@free-expression.org>]

   Marius has written a detailed proposal for a new model, most of
which is dedicated to the nature of modules and scoping rules.
I'm glad he did, because Guile needs some clear direction on
this front.  That said, I'm a little distressed by the proposed
module/variable semantics.
    Before directly commenting, I would like to point out that there
are at least 3(*) orthogonal choices to be made in defining a type of 
environment:

(1)  Is the environment lexically closed or open?  That is, can
      new bindings be added to it, or is the set of
      bindings immutable once initialized?
(2)  Is it a black box to code defined externally?  In other words,
      can values be exported or not?
(3)  Is the code that uses the environment a body or interactive?
      In a (lambda) body, there is a well-defined lexographic 
      boundary between definitions (both variable and syntax)
      and other code (both before and after macro expansion).  
      In an interactive environment, executing
      a lambda at one point in time can result in a "variable not bound"
      error, when at other times it might not.

  Environments that are open in sense (1) are usually referred to as
top-level, though there is no absolute reason such an environment
must in fact be at the top-level. 
   The properties described by (2) could also be called closed and
open.  Indeed, compiler writers refer to exported values as ones
that have escaped (from the optimizer, perhaps).  Unfortunately,
that nomenclature is easily confused with (1).
    Marius' proposed system makes choices <open,open,interactive>.
If by a module we mean a set of code that is meant as a unit for
separate compilation, I believe the right choices are <closed,open,body>
It may be desirable to have other types of environments readily available
as well (perhaps "top-level" environments for each thread that inherit
from a global "top-level" environment?), but I don't believe they should
be considered part of the module system.
    There is no reason to require macros to always be macros.  R5RS does
not have any such requirement and there are plenty of compilers for it.
     I do not agree with the stated use of the word "variable".  That term
has such a standard definition that I believe it is only confusing to
recast it to mean "generic box" (in the "smart variable" case).  A
(global/top-level) variable is precisely its name in a program.  If you
want to make a special generic kind of box that, when bound to
a variable is, let's call it "transparently generic", go for it, but don't
say variables don't have names.
    Rather than tying imported variables to solely to modules, I believe
GUILE should adopt 2 new types of variables, extloc and extvar (or
whatever) corresponding to ilocs and variables, but carrying a reference
to their environment with them.  Space might be conserved by
pointing into a table of environments rather than using a whole
pointer.  In this way we can untie option 2 from options 1 and 3.
    To handle optimization, I believe we could adopt special forms
that import values and bind them to local (possibly immutable) variables.
So (import <module> <variable> ...) would give you a variable such
that side-effects on it are seen by <module>'s code. 
import->local would bind the variable locally to its value in <module>,
                     preserving (im)mutability
import->local/mutable would bind a locally mutable copy.
import->local/immutable would bind a locally immutable copy.
    I believe these would be sufficient for compiler optimizations.  
A "core" module would contain all the basic scheme forms (immutable)
and these could be imported/localized into the top-level interaction
environment, while most modules would just import them directly.

Lynn


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel