[R6RS] Modules

[dyb at cs.indiana.edu]

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

True.  They address both the changes you suggested and the changes Manuel
suggested.

> 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.

I'm aware of this, and this is why I listed this as a point of disagreement.

> 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.

That's true.  I had already compromised with Matthew on this issue.
Note, however, that the proposal addressed libraries but said nothing
about arbitrary application programs, where I would like to allow other
top-level forms, including syntactic definitions that affect the expansion
of subsequent forms.  Matthew, at least, wants to extend the prohibition
against other top-level forms for all programs, not just libraries.

> 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.

This was in response to Manuel's proposal to separate the module
specification from its body.  I'm not clear whether this really
constitutes "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.

This was also in response to Manuel, but the disagreement is probably with
Matthew on whether type declarations should even be allowed.

> 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.

This was also in response to Manuel.

> 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 ...

Okay, so we have another point of disagreement.

> 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.

That's right. The tool (makedepend) that does the corresponding thing for
C requires macro expansion, yet people have been getting along with C,
Make, and makedepend fine for many years.  Here's the first paragraph
of the GNU makedepend manual page:

  The makedepend program reads each sourcefile in sequence and parses  it
  like  a  C-preprocessor,  processing  all  #include,  #define,  #undef,
  #ifdef, #ifndef, #endif, #if, #elif and #else directives so that it can
  correctly  tell  which #include, directives would be used in a compila-
  tion.  Any  #include,  directives  can  reference  files  having  other
  #include directives, and parsing will occur in these files as well.

Are we really willing to restrict our language just because we're
unwilling to write our own makedepend for Scheme?

> 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.

The property is 'destroyed' only to the extent that people actually take
advantage of the ability to abstract require forms, the abstracted
syntax actually obscures rather than enlightens, and you're unwilling to
make use of a tool that performs some expansion and simple analysis to
tell you about the dependencies.

One premise behind prohibiting abstraction of require and provide forms
seems to be that they will make programs harder rather than easier to
understand.  It's true that any kind of abstraction can make programs
harder to understand, but the typical result is to make them easier
to understand.

If someone believes they need abstraction for whatever reason, they
will simply implement it outside of the language using awk or m4 or
whatever, and the result will surely be worse.  Let people use our better
abstraction tools.  Most won't need to, and for their modules even simple
tools will work.

> 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.

I just don't get why this piece of information is crucial and all of the
other information you can't get so easily if you allow the use of macros
elsewhere is not crucial.

Kent