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

Re: A Proposal for Environments in Scheme

    1)  I believe it is a big mistake to require that all environments have a
        name.  There was a good reason(s) for deciding that not all procedures
        in Lisp should have to be named, and I believe that those arguments
        apply equally well to this case.

    I think that you misunderstood the purpose of the <id> argument to
    MAKE-ENVIRONMENT.  It is not a name in the sense that a given name maps to
    a single environment.  Its only purpose is to be some nice thing to show as
    a part of the printed representation of the environment.  It also helps
    humans have a more reasonable handle for talking about environments.  The
    <id> has absolutely no semantic content except that it can be extracted
    from the environment with the procedure ENVIRONMENT-ID.  There are no
    guarantees that <id>'s are unique and no functions for mapping an <id> into
    the environments having it.

It is precisely because the <id> is so often unnecessary, and even possible
misleading, that I feel it should not be required.  I suspect that most people
in the Scheme community would baulk at a required syntax of
(lambda (<id> <args>) <body>) for lambda expressions.  Why should environments
be any different?

    2)  I have been interested in the semantics and use of multiple environment
        inheritance for some time; but, I am not sure that it is well enough
        understood to become part of R3RS.  (Maybe someone else understands it
        better than I do and can convince me otherwise.)  In particular, I am
        concerned about efficient implementations for interpreted code,
        difficulty in understanding code which utilizes this feature, and the
        development of suitable browser technology to make debugging of
        programs using it tractable.
 
    It is easy to implement multiple parents efficiently in the interpreter.
    In Cedar Scheme, environments have two field for parent information; one of
    the fields holds the first parent and the other holds a list of the other
    parents. In almost all cases, single inheritance is used and the
    otherParents field is NIL.  Thus, no consing of environment lists occurs in
    the interpreter.  The variable lookup procedure is straightforward and, in
    the case where otherParents is NIL, is precisely the same as the single
    inheritance case.
 
I am well aware of the obvious implementation of multiple inheritance presented
above.  I was more concerned about whether variable caching schemes like those
used by MIT Cscheme still work with multiple inheritance.  (i.e. Does one still
get the same performance benefits from caching?  If so, how much greater is the
cost of an incremental definition due to multiple inheritance?) 
 
        Should there be an environment analog of
        call-with-current-continuation?  
 
    I've not yet seen a good use for this.
 
MIT Cscheme has this feature and I have seen effective use made of it in the
past, although I don't seem to be able to come up with a clear, concise example
at this time.

					Morry Katz
-------