On Wed, 2009-10-14 at 15:26 -0400, Aaron W. Hsu wrote: > On Wed, 14 Oct 2009 11:53:41 -0400, Derick Eddington > <[email protected]> wrote: > > > On Wed, 2009-10-14 at 01:00 -0400, Aaron W. Hsu wrote: > > > >> [...] > >> > >> So, the module system I propose consists of two forms: > >> > >> <library> := (library [<name>] <exports> . <body>) > >> <name> := #identifier | <r6rs library name> > >> <exports> := (export <export-spec> ...) > >> <export-spec> := #identifier | (#identifier #identifier ...) > >> <body> := (#expr|#def #expr|#def ...) > >> > >> > >> In the above form, [...] > >> I have also made the name of the library > >> optional. This is to allow for anonymous modules, > > > > If <name> is optional, is this ambiguous?: > > > > (library (export foo bar) (export)) > > Yes this is ambiguous, and yes, I missed that. > > > [...] > > > > I think something like this disambiguates: > > > > [...] > > I would propose instead that we force the <name> to be there, but allow it > to be #f. A #f library name means an anonymous library. I think this makes > things simpler.
Yeah, that sounds okay. > >> [...] > >> > >> I have removed, in the above, the import form. This is because this > >> import > >> form should be usable anywhere, and is, in this proposed system, its own > >> form, and not a component of the library syntax. > > > > If there is not an import form as part of the library form syntax, how > > do we know what an import form in the <body> means? There would have to > > be an implicit binding of `import' to the thing which imports. But that > > would make `import' a special keyword which is always implicitly bound, > > which does not seem Schemely. What would this do?: > > > > (library (some lib) > > (export) > > (import (thing base)) > > (define import 'something-else)) > > > > `import' is implicitly bound at the library's top-level, so, the > > definition of another `import' conflicts with the already-bound one. > > You would get an error because you have mutliple definitions of "import" > in the same scope. Based on your other comments in your response, I now understand that the bindings of the environment outside a library form are in scope in the library body (unless `import-only' is used at the beginning of the body). Which means for my example above, if `(thing base)' does not export an `import', then there are not multiple definitions of `import' in the same scope. However, just to mention it, there is the issue that the `(import (thing base))' and the `(define import 'something-else)' are in the same definition context in that order. If your proposal has R6RS semantics for bodies, then it will disallow "defining identifiers which may have already affected the meaning of undeferred portions of a body", which in this case is the definition of an `import' after the use of a different `import'. If your proposal does not have such R6RS semantics, then I imagine it should handle this issue however it would handle such issue in a lambda body. > [...] > > If, in your proposal, imported bindings should not be shadowable by > > top-level definitions, it seems an import form must be part of the > > library form syntax. > > See below, as it does not need to be, and isn't done this way in Chez > Scheme and other implementations. Okay, right. I was missing that your library form is similar to Chez modules in that there is an outer environment in scope in the form. > One of the main points of my proposal is that the Library system isn't its > own "description" language that exists as wrapping all Scheme code; it > *is* Scheme code. In order to evaluate Scheme code, one must have an > environment defined already. [...] > > [...] Sounds like a win to me. [...] Yeah, it sounds promising. I hope it gets the expert attention needed to fully explore it. -- : Derick ---------------------------------------------------------------- _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
