Re: [Chicken-hackers] [PATCH] Add unexport form for modules

[Peter Bex]

On Wed, Jun 07, 2017 at 12:41:03PM -0400, John Cowan wrote:
> On Wed, Jun 7, 2017 at 9:28 AM, megane <address@hidden> wrote:
> 
> If the module export list is not *, module-unexport-list is not used. In
> > this case, it's enough to just remove the identifier to be unexported
> > from the module-export-list.
> >
> 
> Very nice!
> 
> While you are messing around with the module system, I'd like to see
> "strip-prefix", which is just like "prefix" except it removes a prefix from
> identifiers (if present) rather than adding one.

Both these proposals make me very very uneasy, for slightly different
but somewhat related reasons.

Warning: what follows turned into a long rant.  Please bear with me.

Unexport seems to me to be solving a non-problem.  Exporting * always
seemed questionable to me, since it is too implicit and very error-prone.
It's very rare that you don't introduce *any* helper procedures or
macros.  In fact, introducing "unexport" just to paper over the problems
that exporting everything creates seems like the wrong direction to me.

But my more immediate concern is with proliferation of the magic set of
special forms that's always available in a supposedly "empty" new
namespace that a new module represents (the "initial macro environment").
In CHICKEN we have these:

- import
- import-for-syntax
- reexport

then there's these, which currently seem to be nicely put away in the
"chicken" namespace in CHICKEN 4, but in CHICKEN 5 are initially
available (might want to take a look at why that is...):

- begin-for-syntax
- import-syntax (WTF)
- import-syntax-for-syntax (WTF)

And "chicken" exports this in both chicken-5 and master:

- export (which I always found rather useless, given that you have a
   list of exports right at the top already)

Now we are discussing adding "unexport" onto that set.  Ideally, the
initial module environment should be empty.  As in, completely void,
a blank canvas.  This allows for maximum flexibility in whatever the
user wants to define inside the module.  R7RS small avoids the problem
of polluting the initial environment by strictly separating the library
definitions from the Scheme code within it (the Scheme code must always
be wrapped in (begin ...)).

By doing this, R7RS allows for an almost infinitely extensible
"library language", that will never pollute the Scheme module inside.
Unfortunately, because it's not Scheme, this language isn't (easily?)
programmable by the user.  CHICKEN mixes up both things somewhat by
having this initial macro environment.  I'd prefer if we can avoid
adding *any* new identifiers to this macro environment, to avoid
stepping on the user's toes.  So without a change in how the module
language works I'd be against this change.  FWIW, I think making this
change is probably the Right Thing(TM), but also probably a too large
change to do now, in CHICKEN 5.


Regarding drop-prefix, it makes me uneasy because of the dual use
of symbols and lists as library identifiers.  In R7RS, again, you
have an "import set" which is any of (only ...), (rename ...),
(except ...) or (prefix ...) or a "library name", which is ALWAYS
a list.  So there's no ambiguity whatsoever: you can have a library
called (rename file pattern) and it can always be distinguished from
a rename of an identifier from a library, because "file" and "pattern"
are not valid library names.

In CHICKEN, we allow both "(file)" and "file" as a library name, so
there's an ambiguity.  With every new import option we add we make
this problem worse.  I would prefer us to reconsider allowing this
duality by either going the R7RS route and requiring the identifier
to always be a list, or dropping the list syntax altogether and
only allowing symbols.  Without this change, I'd be EXTREMELY
hesitant to add any more import operators.

Regarding the list syntax versus symbols, it would be easier on
our users, porting-wise, to only allow symbols as library names.
It also maps more clearly to the file system.  Aesthetically and
for compatibility with other Schemes, I'd prefer the list syntax
only.  But accepting both is (in hindsight) quite the mistake.
We can still change things before it's too late...


Cheers,
Peter

signature.asc
Description: Digital signature