[r6rs-discuss] A different take on libraries

From: MichaelL_at_frogware.com <MichaelL>
Date: Wed Nov 15 09:42:17 2006

> I think there's another way to go, though. Imagine, for example, that
> libraries were designed the way that records are. Imagine that there was
a
> procedural layer, and that the syntax was built on top of the procedural

> layer. Imagine for a moment that part of the procedural layer looked
> something like this:
>
> library-exports
> library-locals
> library-imports

I just wanted to add some further examples of how a procedural interface
could allow new possibilities.

If you could add to the list of library exports at any time* then you
could build PLT's "provide" mechanism. That would allow you to export from
within a library body. That, for example, might be useful for syntax.

If you could add to the list of imports at any time* then you could build
Chez's "import" mechanism. That would allow you to import from within a
library body. That's particularly useful if libraries can be nested; it
would allow you to include some other library form into the current
library scope and import it into that scope (and only that scope).

If you could clear the list of locals at any time* then you could build
Chez's "import-only" mechanism. That would allow you to establish a
"language" for a library body. (In Chez, "only" means "only." If what you
import-only doesn't have bits of Scheme, those bits are no longer
available. I think that's along the lines of what PLT's language
specification in a module tries to do.)

Clearly all of these things are doable; implementations do them now.

=====

*"at any time" obviously has limits. For example, a compiler would need to
know that, past some point, a library's imports and exports and locals
won't change. To accomplish that the procedural interface could, for
example, support sealing or finalizing the library. When a library was
sealed it could verify that all exports have been satisfied. That would be
in keeping with PLT's provide; PLT allows provide forms before identifiers
are defined.
Received on Wed Nov 15 2006 - 09:41:49 UTC