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

[Peter Bex]

On Thu, Jun 08, 2017 at 10:39:45AM +0300, megane wrote:
> Peter Bex <address@hidden> writes:
> > 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.
> 
> The only reason I'm using * export is to export is structs. That is,
> automatically exporting all defines created by a defstruct call. I
> already have a wrapper for defstruct, so maybe I should just export all
> identifiers from there.

That might be a bit saner but still very implicit, or unhygienic.  But
then so is defstruct.

> Maintaining the export list by hand is just busywork to me. So I only
> use either empty export list or *.
> 
> Nice thing about empty export list + export or * + unexport is that you
> can conditionally export all identifiers for e.g. unit testing.

The typical way to do that is to put the module definition in another file
than where you put the definitions.  Then you can simply
(include "defs.scm") in the tests and in the module.  But yeah, this is
a bit unwieldy, I admit.

> Why not just move all the module syntax to a new library? You currently
> have to have '(import chicken scheme)' in the beginning anyways.
> Wouldn't be a big deal if you had to add module-syntax and
> module-syntax-yolo there as well.

Yeah, that's what Evan suggested as well, and I like that idea.
I wouldn't mind having unexport in (chicken module) or so.

> I don't like this drop-prefix because that would make editor support
> harder. Say you want to look-up documentation for an identifier. With
> drop-prefix the editor would have to understand the import statement and
> go looking for the identifier for all modules for which you had used
> drop-prefix. OK, not a big problem, and applies to the current rename
> facility as well.

Yeah, that's not really a fundamentally different problem.  It'd be nice
if someone wrote some tooling around all this stuff to make code
navigation or even refactoring easier.  And I'd like a pony.

Cheers,
Peter

signature.asc
Description: Digital signature