Re: comments on new-model.txt [long]

[Marius Vollmer]

Lynn Winebarger <address@hidden> writes:

> On Tuesday 24 September 2002 15:03, Marius Vollmer wrote:
> > Lynn Winebarger <address@hidden> writes:
> > 
> > > So part of the miscommunication is that I've stopped thinking of
> > > "top-level" (lexically open) environments necessarily being at the
> > > actual top-level of a lexical environment.
> > 
> > What is there instead, then?  Or, where would the open environments
> > be, if not at the top of lexical environments?
> 
>     Well, the clearest example I can think of is in a threaded model. 
> Each thread could have its own top-level, _above_ the thread-global
> top-level environment.

Thus, in such a model, a identifier could reference different
variables depending on the thread that executes the code that contains
the identifier?

This would indeed be something that is not covered by new-model.txt,
but I don't really want to go there.  I think we should not get too
dynamic with variable lookups.  Instead, we might have smart variables
that do fancy things upon access.

> These would essentially play the role dynamic roots play now, but
> hopefully with cleaner (or at least uniform) semantics.

How are our current dynamic roots related to variables and modules?

> > > It complicates define a little, but not much.
> > 
> > Can you spell out this complication?  I think that will help me to
> > understand better.
> 
>     Well, it's just _where_ will a define do its business.  Let's say
> I am interpreting `(define x 5) in the environment 
> `(,toplevel-B ,toplevel-A).

Aha!  I think I get it now.  In my model, a chain of environment
frames always ends in a single 'toplevel' frame that points to a
module.  In your model, frames which point to modules are not
restricted to be at the end of the chain, right?  There can also be
two frames pointing to different modules, like in your example above,
right?

Is there a system that works like your example?

Could we achieve the important eefects of your example by creating
modules that mimic them?  That is, instead of allowing more than one
module-frame at the end of a frame chain, could we implement a module
that, when put at the end of a chain, would behave as if two
module-frames would there?

>   If x isn't bound in either A or B, it's clear (I think) you want
> to create a binding for x in B (not A).  Likewise, if x is bound in
> B, then the define should just act as a set! on that binding.  Now
> what happens if x is bound in A?  Should the define just be a set!
> on the binding in A, or create a binding in B?

We have already a situation that is similar to this: importing
bindings from one module into another.  The new-model.txt is not
really affected by this; this needs to be addressed by the module
system (which I don't really want to talk about here).

> > [connection between a module mentioned at compile time, and the
> > corresponding module used at run-time.]
> >
> > It would be a win if we can make that connection in a way that doesn't
> > rely on module names.
>
> We can. [...]

Sorry, I don't see how from your explanation.

> > > (define a (load-module "foo"))
> > > (define b (load-module "foo"))
> > > (import a (prefix "a->"))
> > > (import b (prefix "b->"))
> > > (set! a->bar 5) 
> > > (set! b->bar 7)
> > > a->bar => 5
> > > b->bar => 7
> > 
> > How would this work with macros?  'a->switch' might be a macro, but
> > the compiler might not be able to figure this out since it can not
> > know in general what 'a' refers to.
>
>      As long as you can assume that "foo" refers to the same
> compiled module at compile time (on the developer machine) as at
> run-time (on the user machine),

(I think we can assume this.)

> or some reasonable variant thereof (via some versioning mechanism),
> then I think the compiler can know whether its a macro or not.

In your example, yes.  But what about code like

    (define a (load-module (string-append "fo" "o")))

Is the compiler required to figure out what the string-append form
evaluates to?  I think it is easy to see that this does not work in
general, for more complicated code.

>      I meant you could use modules as an object system with compiled
> methods.

Do we want that?  That seems like a too large step to me.

> > Could your macro expander be made to work with the new-model?  I.e.,
> > assume you need to produce macro-free Scheme plus a few extensions
> > like ':module-ref'.  Could it do that?  You can assume that you can
> > use real uninterned symbols for local variables (so that there wont be
> > any clashes between renamed local variables and global variables).

>       It is difficult, I think, because (if I'm not mistaken) the
> reason the current module system is "interesting" is precisely
> because variables aren't looked up until they're actually used

No, I don't think so.  In any case, the lazy lookup is not required by
new-model.txt.

> (part of the "lazy" macro expansion, except "lazy" usually refers to
> something that has the same outcome whether you were lazy or not,
> except not halting).  Once they're resolved, aren't top-level
> variable occurences replaced with references to bindings in the
> current module environment?  Or do top-level variables get
> repeatedly looked up?

They are replaced with references to 'variable' objects.

>    That said, it's not impossible.

Ok.  Can you modify new-model.txt so that it is to your liking?

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