[R6RS] Modules

[Michael Sperber]

Kent---

I'm confused about some parts of your response, as they don't seem to
address the actual strawman proposal I sent.

>>>>> "Kent" == R Kent Dybvig <dyb at cs.indiana.edu> writes:

Kent> - Implicit export declarations should always be required, for reasons
Kent>   I've already stated.

You've made a point why they're good (which is why they show up in the
proposal)---but haven't really convinced all of us that they should
*always be required *for SYNTAX-RULES**.  I'm fine with always
requiring it for SYNTAX-CASE.

Kent> - We should be able to write macros that expand into require, provide,
Kent>   and even module forms.

But the proposal you presented in Snowbird didn't have the ability
to have macros expand into MODULE forms.

Kent> - While I don't mind including support for separate interfaces, they
Kent>   should not be required.

My proposal doesn't say anything about separate interfaces.

Kent> - While I don't mind including support for type declarations, they
Kent>   should not be required.

My proposal doesn't say anything about requiring type declararations.

Kent> - There should be a standard way for a require forms to specify where to
Kent>   look for implementations of the required modules.  

My proposal specifically suggests that we do this.

Kent> We may be able to resolve, in a sense, some of our disagreements by
Kent> giving some things the "it is an error" label, as Matthew has suggested,
Kent> and leaving other details implementation dependent, but this will not
Kent> give us truly portable libraries.

I don't see why this is true---Scheme 48 has a specified separate
configuration language that people use.  Nevertheless, that language
is implemented as a bunch of macros.  In theory, people could write
macros that expand into module definitions.  It's even possible to
write macros that expand into "require" forms.  Still, it's something
that people don't do, even though portability isn't an issue.

My proposal is (except for the initial language issue---but there'd
surely be room for compromise there) easily implementable in terms of
yours.  It's easily powerful enough to specify portable libraries.
Sure, people will make mistakes writing portable code by using
extensions offered by one implementation not mandated by the standard,
but that's true of any language extension.

Kent> * Why are any changes to my proposal necessary to allow the use of
Kent>   Unix "Make"?  In particular, having a separate specification language
Kent>   is not necessary, and being able to determine requirements without
Kent>   expansion is not necessary, or Make could not be used for C.

I guess I worded this in a confusing manner: My proposal says "perform
make" in the sense of "do automatic recompilation for a set of
modules."  This includes building the dependency graph, which is
something that make doesn't do.  The tool that does it does require
macro expansion.

Kent> * If actual requirements are specified via some external configuration
Kent>   language, why do we need a require form at all?  If it's just to
Kent>   specify the particular set of identifiers that need to be made
Kent>   visible from a required module, why is there any resistance to allowing
Kent>   abstraction of require forms and/or require forms to appear in local
Kent>   scopes?

That's because of the rationale for a separate configuration language:
The objective of a separate configuration language is to make it
easily visible where identifiers come from.  Sure you can use
non-hygienic macros to make other identifiers visible, but these can
only come through uses of such a macro---and the use is easily
identifiable.

Once you have local require forms, you automatically introduce
abstraction.  Once you introduce abstraction, you destroy that
property.

Kent> * For those who favor separate configuration information, what do you
Kent>   anticipate a Scheme shell script that requires one or more portable
Kent>   modules will look like?  Will all scripts have to have separate
Kent>   configuration and/or Make files?

No---my proposal specifically allows for configuration and actual
source to exist in the same file.

Kent> * For those who want require and provide forms to be hard-wired so that
Kent>   they can be processed by external tools, would you extend this argument
Kent>   also to the definitions appearing with the body of the module?  If not,
Kent>   why not?  If there is useful information to be gleaned from the require
Kent>   and provide forms, there is surely even more useful information to be
Kent>   gleaned from the actual definitions.

You're right that we're drawing a line here: All the exports go
through an (implicit or explicit) interface, where they're explicitly
named.  With fancy macros, you can hide the fact that you're writing a
definition.  However, once you want to export that definition, you
have to name it.  That provides the crucial bit of information we're
looking for.

-- 
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla