This page is part of the web mail archives of SRFI 83 from before July 7th, 2015. The new archives for SRFI 83 contain all messages, not just those from before July 7th, 2015.
On 12/3/05, Taylor Campbell <campbell@xxxxxxxxxx> wrote: > > [...] My suggestion is this, > based on Scheme48's module system: that module descriptions be in a > simple language distinct from Scheme, which would be in general > placed in a file separate from those of the source code of modules' > implementations. It took me a while to realize this, but module descriptions *are* in a simple language distinct from Scheme in the current proposal. That language is: (library <module-name> <language> <impexp-form> ... <body> ...) It is a very limited language, and can only be extended by adding new forms like <IMPEXP-FORM> which effectively become reserved words. If you import a library that provides a form called IMPORT or EXPORT, this specifically has to be avoided as the first expression in <BODY>. Though this may not be likely with those particular identifiers, as <LANGUAGE> is extended to allow more module declarations it becomes increasingly likely that there will be a conflict. [To reiterate a previous post, prominently allocating a required positional argument for <LANGUAGE> doesn't make this any more or less extensible than an optional (LANGUAGE <...>) form.] The Scheme48 approach would look more like (library <module-name> <impexp-form> ... <other-declarations> ... ;; either (code <body> ...) ;; or otherwise (file </path/to/file/containing/body>)) There are effectively no reserved words, since nothing in the <BODY> could occur in a position that could be a declaration. This allows it to be more easily extensible, to the point of making the declaration language Turing complete, should one desire (as an implementation-specific extension, of course, since the standard will remain minimal). Both code directly in the file as well as in a separate file are possible (as they are in every solution seen so far). Of course, since most Schemers prefer to keep everything in the same file (including documentation and at times even test-suites), the CODE form would likely be by far the most common. The disadvantage of this is that it requires a little more typing and yet *another* level of indentation (or possibly another ignored level of indentation if you're going to indent to column 0 anyway). An alternative approach is to reverse the assumption, so that instead of an implied body of declarations, a module is an implied body of code, and the declarations are kept in a single form (to stretch the imagination a little we'll call it DECLARE): (library <module-name> (declare <impexp-form> ... <other-declarations> ...) <body> ... ) A possible declaration could be FILE (or INCLUDE) for those who prefer to keep the code in a separate file. As a slight variation, since there will be declarations in almost all cases we could require the declarations to be the first form after the module name, and just assume the DECLARE keyword without writing it - that is, just include all the declarations in a single extra paren grouping. For example: (library http ((import net) (export call-with-input-url)) (define (call-with-input-url url) ...) ...) [Disclaimer - I've just described the module declaration syntax for Common-Scheme, modulo keyword names.] -- Alex