You know, the conservative, incremental thing to do would be to add something along the line of fexprs and first class environments and let the rest sort itself out in libraries. Compiler freaks (bless them) are free to handle only certain subsets of such a core plus libraries, punting the rest to an interpreter.
It's conservative and incremental because it just floats some existing elements of the semantics into first-class values. It's practical because, well, it's been done more than once. -t On Thu, 2009-10-15 at 18:20 -0400, John Cowan wrote: > Aaron W. Hsu scripsit: > > > I would like to make a counter-proposal to your module proposal. The > > proposal is at > > > > > <http://my.opera.com/arcfide/blog/2009/10/14/a-philosophy-on-scheme-modules> > > Here's my response. I'm using the text in your blog post as of right now, > folding in the updates. > > > Moreover, I believe that this initial module system should be simple. It > > should not require a great deal to understand the core constructs. > > Your module system is many things, but I don't think it's simple. > > > It should also be backwards compatible, such as can be done, with > > R6RS libraries. > > It's backward compatible with a subset of them, which is to say not > really backward compatible at all. Details further down. > > > <library> := (library <name>|#f <exports> . <body>) > > My general objection here is that you shouldn't use "library" as the > name of something that doesn't have the semantics of an R6RS library. > > > <export-spec> := #identifier | (#identifier #identifier ...) > > I take it that this means the same as in Chez; specifically, the second > form exports a syntax binding with its implicit exports. However, it is > incompatible with R6RS, for which "(foo bar)" means "export foo as bar". > > > <body> := (#expr|#def #expr|#def ...) > > I like this. > > > The major difference here is not in the form, which is basically the > > same, but in the fact that this form should be syntactic, in that > > you can generate it from macros. It should be possible to nest these > > library forms. I make no arguments about how they should map to files, > > since this should be up to the implementation. > > But you do have to answer, I think, the question of whether importing > implies loading, implies an attempt to load, or only works if the > module is already loaded. I take the middle view, as I assume that the > implementation knows how to load some modules by name but not others. > > > (only <import-spec> #identifier ...) | > > (except <import-spec> #identifier ...) | > > (prefix <import-spec> #identifier ...) | > > (drop-prefix <import-spec> #identifier) | > > (rename <import-spec> (#identifier #identifier) ...) | > > (alias <import-spec> (#identifier #identifier) ...) > > I hate to employ the old saw, but this really does look like piling > feature on feature to me. What is it one really needs at import time? > The ability to either import the names of a module directly into your > namespace, perhaps overriding other imported names, or import the names > into a segregated region of your namespace. That is, either direct > import or prefixing import. Everything else is inessential, just a > matter of lexical prettiness. > > > The above is a combination of R6RS and Chez Scheme module import forms. > > Multiple specs may be listed in a single import form, but drop-prefix > > and alias have been added. > > My objection to drop-prefix is that it forces the importing module to know > what should be a private feature of the exporting module: what prefix > it internally uses for names it chooses to export. Therefore prefixes > should be stripped at export time. This can be done in R6RS painfully > by renaming each exported name. There should be a way to do it en masse. > > > The use of import-only means that only those identifiers imported > > from the import specs listed will be visible in the scope that the > > import-only form affects. This is useful when you want to generate > > these module forms. > > The distinction between import and import-only is fundamentally whether > this module implicitly imports its lexical environment or starts with an > almost empty environment. I suggest that this distinction be lifted to > the library level, perhaps by different syntactic keywords. (This does > not count as two module systems.) > > For example, you could use library for the kind that imports its > environment, and empty-library for the kind that doesn't. Or you could > use library for the kind that doesn't import, and local-library for the > kind that does. > > > I am also proposing that include, and possibly include/ci be a part > > of the standard. This will easy the creation of module and source > > code separation. > > Please see my write-up on case sensitivity. In short, a case-preserving > module should see case-folding modules as all lower case (lower case, > because Unicode case folding is lower-casing for technical reasons); > a case-folding module can use |...| syntax to specify case-insensitive > names. > > > "This is just syntactic macros, you're just selling out the static > > package folks," I hear you say! No, actually, I am not. I am suggesting > > a standard module system that is general enough to be used by both > > crowds. The syntactic module crowd won't have to develop any new syntax > > to use this system, and the static crowd will have to do some extra > > macrology; this is true. > > For "some extra macrology" read "execute an arbitrary amount of code at > phase 1 to determine dependencies at the module level", given low-level > macros. That's a *long* way from being what "the static crowd" would > reasonably want. I fear you are, in fact, selling them out. > > > Obviously, the drawbacks of this system are that by default, it ties > > the library system to code evaluation, which many people consider a > > bad thing. The R6RS library form does this as well. > > I don't see how. Everything about an R6RS library except its actual > implementation can be determined by reading it in with READ and examining > the first few elements of the resulting list. > > > Yes, the module system above will require some extra work to make a > > suitably sophisticated system on top of it that will satisfy the needs > > of the static description language crowd. > > It can satisfy them as to their own modules by mere self-discipline: > don't use any of the extra flexibility. It cannot satisfy their desire > for trivially consumable metadata for *all* modules, a la R6RS, Scheme48, > or SRFI 7. > > > The above system is also fully backwards compatible with the R6RS > > library standard, making the transition to the new module system that > > much easier. > > Only syntactically. > > > I should note that because library forms in this proposal are syntax, > > they are just Scheme code, and as such, the implementation is presumed > > to provide some default environment, likely to contain the library > > forms. > > At least the library and import keywords, as a practical matter. > _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
