[R6RS] Re: strawman module syntax

[R. Kent Dybvig]

First of all, let me repeat that I'm not trying to take anything away
from anyone.  If, for example, one wants to structure his or her code in
such a way that each file contains a single module with a fixed set of
require forms, that's no problem in the system I propose.  If one want's
to set up an SCPAN repository and require all files in the repository
to have that form, that's no problem.  If Matthew's tools work only for
files in that form, that's no problem.  Just let others write their end
applications and scripts in whatever form they like.  In other words,
the kind of restrictions you propose should be a matter of policy to be
applied in appropriate contexts, not language limitation.

> While this may be a nice language design aspect, it fails to take into
> account separate compilation and how pieces of code residing in
> different files refer to each other while avoiding name conflicts.
> (Matthew is arguing why things shouldn't expand into top-level MODULE
> from another angle.)

> Could you elaborate on this issue?

As I understand Matthew's proposal, the language specified by the implicit
require form determines the syntax for the entire contents of the module,
including explicit require and provide forms, if any.  So it's not
possible for a compilation system to determine what a module requires
or provides without expanding macros.

I assumed the same was true of your proposal, perhaps incorrectly.
I'll assume for the moment that you intend for your module clauses to
have a fixed syntax regardless of the language.  Under this assumption,
your compilation system can determine which modules from which files are
required by a given module without expanding macros.  But it can't do
any more than this without expanding macros, so the benefit is limited.
The costs for this limited benefit, in my opinion, are too high.

If it's important to know the set of modules and/or files involved
without macro expanding the code, then perhaps we should separate the
specification of file/module requirements from the specification of
identifiers to be imported from the required modules.  (Imports should be
specified as locally as possible to reduce namespace clutter and increase
security.)  But I would prefer that the set of modules and/or files be
determined as locally as possible as well, since top-level declarations
of requirements tend to go stale.  (I have on numerous occasions found
unnecessary header files in C applications and unnecessary libraries in
the corresponding Make files that I assume came about because they were
once needed by some code in the file that was later modified or deleted.)

> Kent> Thank you for the clarifications.  Unfortunately, I strongly dislike
> Kent> several aspects of the proposed design.  One of Scheme's charms is that
> Kent> 3 is a program, and not just in the interactive environment.  There's no
> Kent> barrier to entry, no boilerplate stuff to stick on the top of or wrap
> Kent> around each file.

> But neither the design Matthew proposes nor mine precludes that---and
> the email you followed up to contains a note on that.

Here was my question and your response.

  > Kent> From your syntax, I take it that an application cannot contain
  > Kent> any top-level forms other than config forms, so top-level
  > Kent> definitions and commands are out.  Correct?

  > Yes.

  > ...

  > Note that I'm not proposing to abolish the interactive top level.

You certainly seem to be saying that 3 isn't a program except in the
interactive environment.  What am I missing?

Kent