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