[Jscheme-devel] RE: Modules, Macros, and Eval in Jscheme

[Derek U. <Der...@on...>]

> One more small change.... I've modified DynamicEnvironment.java so that
> when a new environment is imported, it only imports those variables whose
> names do not contain ":"  under the assumption that such variables were 
> themselves created by a higher level environment import.
>
> We could require import prefixes to end in a ":" or we could just use 
> the colon to indicate variables that should not be exported, e.g.
>    (define (local:f x) {This is a non-exported function with parameter
[x]})
> With this model the user would be responsible for picking import 
> prefixes that didn't cause name clashes...

We definintely need to re-think this.

I'm not convinced that there's any need to prevent the export of symbols.
The reasons for doing that generally boil down to (a) data hiding and (b)
preventing inadvertent collisions.  Data hiding has never been a tremendous
selling point for Lisp languages, and collisions shouldn't be a problem when
loading ``system'' libraries where you

  * load them at the beginning of your file, and
  * never change them after you've loaded them.

The fact that there's a "foo:bar:baz:do-stuff" symbol in the top-level
environment with you shouldn't matter; either your code will change the
binding to something you wrote, or you won't be paying attention to the
symbol at all.  (Not exporting recursive symbols saves speed and memory,
since you'd be copying fewer bindings, but it's not worth optimizing that
yet).

But the real problem with this is that it breaks existing code.  One feature
of the original mechanism was that you could import new-style modules, *or*
old-style Scheme code with explicit colons in their identifiers.  They'd
both appear the same when used in your code, the only difference being the
use of "pp:" or #f in the import directive.  Using colons to mean "don't
export" would force you to use a different mechanism to load, say, SLIB.  I
consider that to be a major bug.

How about we back out this particular change for now?  I'd like to use the
module system for a bit with the current ``promiscuous'' export.  It'll give
us a chance to see where the rough spots are.  If we do decide that we need
strict export/import, we can do that as a successor project.  In particular,
the choice to export a binding or not should be a property of the binding,
not something implicit in the naming convention.  (Especially when the other
half of the Scheme community uses hyphens to separate module names...)

Derek