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

[Peter Bex]

On Thu, Jun 08, 2017 at 11:19:05AM +1200, Evan Hanson wrote:
> Hi Peter,
> 
> Firstly, thank you for the writeup. It takes time and energy to consider
> design issues like this, and your effort is appreciated.

No prob.  I really wanted to preempt adding more features without
considering the consequences first and wasn't sure where the other
hackers stood.

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

I'd like that.  If the only things you have is forms to import other
things, you can get everything else from there.  Perhaps even just
"import" is enough, as you could import import-for-syntax first
(optionally renaming it), and then use that to import stuff for your
macro transformers.  I *think* that wouldn't cause any phasing issues.

In fact, maybe we can get rid of import-for-syntax.
(begin-for-syntax (import foo)) should be equivalent to
(import-for-syntax foo), right?

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

I'd like that.  Or, if like you propose below, we add the other
export/reexport etc forms to chicken.module, we can add it there.
But chicken.syntax is probably the best place.

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

The WTF was because I typed this message at too late an hour and didn't
remember what these did.  They're there to avoid the import from actually
loading any code, right?  Perhaps if we get rid of import-for-syntax we
can also get rid of import-syntax-for-syntax on the same grounds.  Then
we'd have just "import" and "import-syntax" in the initial macro
environment.

Perhaps later we can add some optional thing to the module form to allow
changing what they're called.  But for now we're good.

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

Yeah, I think you're right.

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

Yeah, reexport is obscure.  Why do we need it again?  And to me, export
only makes sense if the module form doesn't have an export list.
Combining the two is just weird.

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

Yeah, like I said, R7RS's library system isn't programmable (AFAICT), and
that's a bit weird for a Lisp, which is the ultimate "programmable
programming language".  Having module forms be part of the language we
can do a lot more, for example having the s48-modules or r7rs module forms
available as pure user-level extensions wouldn't (as easily?) be possible
with the R7RS library, I think (nor would something like this be possible
with the s48 package declaration syntax).

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

Preferably only import.  You can get export and reexport by importing
them.

> And, when you look at the current list of identifiers, we're not even
> far off that mark.

Agreed, we're in better shape than I thought before I started to type
that little rant ;)

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

Yeah, let's do that.

> > [about module syntax as lists or symbols]
> 
> 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".

Or "only", or "except", or "prefix" (or, with this proposal, "drop-prefix").
And adding more makes this problem bigger.  And if we release chicken 5
like it is now, and later we add things like drop-prefix, we risk breaking
code like (import (drop-prefix string)) that worked perfectly before.

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

Agreed.  But if we do that, we make the problem open-ended and allow the
user to unwittingly break existing imports in other people's code by
defining new import transformers for their own code.

> ... But not in version 5.0. :)

Emphatically agreed!  But I do think we should take a stance on
allowing only symbols or only lists as module names to prevent problems
in the future beyond 5.0.

Cheers,
Peter

signature.asc
Description: Digital signature