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

[Marius Vollmer]

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?

> It complicates define a little, but not much.

Can you spell out this complication?  I think that will help me to
understand better.

> > [...]
>     No.  There's no (good) reason for modules to have inherent
> names.  There are good reasons for them to have fixed file names,
> but not names that inhere in the module itself (any more than there
> is for functions, at least).

Yes, good point.  The model does rely on module names only for the
'module-ref' statement.  That statement is meant to be used by macro
expanders so that a macro expansion can refer to names from the module
of the macro definition without having to export/import those names.
It would be a win if we can make that connection in a way that doesn't
rely on module names.

We can change ':module-ref' to allow arbitrary code to be executed for
retrieving the module.  That is

  (:module-ref MODULE ID)

would refer to the binding named ID in the module returned by
evaluating the expression MODULE.

But how are the identifiers of the expression MODULE looked up?  Maybe
it will work to specify that it is always evaluated in the "(guile)"
module.

That is quite a complicated scenario, in my opinion.  I think it is OK
to just require that modules that are used in a ':module-ref'
statement must be findable via names.  Parameterized modules can
embedd the parameter values in their names, like
(scheme-report-environment 5).  When parameterization gets more
complicated, we probably should use GOOPS instead of modules for this.

> (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.

A solution would be to say that you can't _only_ compile some code,
you can only execute it and (optionally) compile it at the same time.
This is something to keep in mind, I'd say.

>   So in this model, you could use modules you object with compiled
> methods if you like.

I don't understand.  Come again? ;)

>    If you can't tell, I think Guile should handle its own linking
> and loading, at least as far as its own compiled modules go.

Yes.  I want 'load' to load compiled code as well.

>    As regards syntax-case and macros/modules: I don't believe Guile
> should use Dybvig's portable Scheme implementation.

If we get something better, great!  But this is a separate issue, I'd
say.  (Larceny has a nice compiler front-end, I think.)

> Even if it we had a compiler, it does explicitly use symbols for
> renaming that somehow have to be unique across compiler runs.

Hmm, the renaming is only done for local variables, not for the global
ones.  We have a problem right now because the renamed local
identifiers might clash with the not-renamed globale ones, tho...

> (define foo-macro 
>   (lambda (x)
>     (syntax-case x ()
>       ((_ y ...)
>        (let ((z +))
>          (syntax (z y ...)))))))

Shouldn't that be 'define-syntax' instead of 'define', or am I missing
something?

>   Really, this is just an attempt to import z from the let inside of
> foo-macro into the environment in which "foo" is expanded.
>
>    Now, what should happen when a macro imported from the module is
> used is the same: newly introduced identifiers should get labeled by
> the module environment, and everything else should retain whatever
> lexical environment it had.  This will avoid both capturing syntax
> from the interactive top-level, and missing syntax from the module.
> Since macros are perfectly capable of relying on values of imported
> variables (and side-effects on those and resulting dynamic macro
> behaviour), And macros can introduce macros they imported from yet
> another module, it will all work (I think, anyway).

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).

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