Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames)

Brian Fox brianf at
Wed Apr 26 17:27:30 UTC 2017

On Wed, Apr 26, 2017 at 12:27 PM, <mark.reinhold at> wrote:

> If one of those automatic modules is modularized later on, and given a
> different name, then how is having to fix that materially different from
> having to fix code that was using a package that's no longer exported?
> If anything it might actually be easier to cope with a module-name
> change, since all you have to do is edit a `requires` directive; code
> that refers to a package that's now encapsulated might require a
> non-trivial rewrite.
> I think I need to reconsider my previous conclusion that explicit modules
> that depend upon automatic modules should never be published for broad
> use [2].  Sure, they have unstable names and unstable APIs but if, as you
> say, people are generally used to fixing minor problems when they upgrade
> then this instability may well be tolerable -- especially since it would
> allow maintainers to modularize whenever they want to rather than only
> after all of their dependencies have been modularized.

One is an edge case, the other is the normal case. Just because _some_
people will have to fix their dependencies, doesn't mean we should choose a
path that forces _all_ users to deal with names changing all over the place.

More information about the jigsaw-dev mailing list