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

[Evan Hanson]

Hi Peter,

Firstly, thank you for the writeup. It takes time and energy to consider
design issues like this, and your effort is appreciated.

On 2017-06-07 22:07, Peter Bex wrote:
> 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

These make sense where they are to me. Maybe reexport could go in
"chicken" (or "chicken.module", eventually, as in c-l-r).

> 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

Agreed, this doesn't need to be in the default environment. I don't
think this difference between CHICKEN 4 and 5 is intentional.

Shall we put it in "chicken.syntax" (what is currently "chicken.expand")
instead?

> - import-syntax (WTF)
> - import-syntax-for-syntax (WTF)

Why WTF? These import syntax. Do you have a better name for them? Or do
you think they should live in a separate namespace from "normal" import?

These didn't exist in CHICKEN 4, and when they were added to CHICKEN 5
we put them next to the existing import form. I still think that's
where they belong.

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

I like export, personally (in fact, I'd rather do away with the module
list, but that's neither here nor there), but I do think it's odd that
it lives in "chicken" while reexport is in the initial environment. They
should either be swapped or moved so that they're both outside the
default namespace.

(Personally, I think reexport is the strange one here, but that's
another topic for another day...)

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

I don't think this change is right for CHICKEN. I see the value in
having a separate library language, of course, and I understand why R7RS
works that way, but that's not how CHICKEN works, and in my opinion it's
the wrong choice for a Scheme that's aiming to be pragmatic overall.

This being the case, the initial environment can't be empty, but should
contain only module-related syntax, i.e. import[-*], possibly export,
and possibly reexport. And, when you look at the current list of
identifiers, we're not even far off that mark. The only questions are
where export and reexport should go and whether we want an unexport form
to boot. These things can go wherever we like. If we feel that the
initial environment is too crowded, we can put them in "chicken.module"
instead.

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

The list syntax is better for most things, of course, but there are
important situations where it's simply unwieldy, such as when referring
to modules on the command line. Supporting both really doesn't seem like
a burden to me. Just don't start a module with "rename".

That said, "drop-prefix" does seem a bit much. Rather than introduce
more single-use features like that, I'd prefer to add some extensibility
whereby users can plug in their own "import transformers".

... But not in version 5.0. :)

Cheers,

Evan

signature.asc
Description: PGP signature