[racket-dev] submodules

An hour and a half ago, Matthew Flatt wrote:
> If I understand what you mean, then all of the interesting uses I
> see involve extracting a submodule from the outside:
> 
>  * Extracting the `reader' submodule of a given module.
> 
>  * Running a `main' submodule of a given module.
> 
>  * Running a `test' submodule of a given module.
> 
>  * Getting documentation information for a given module.
> 
>  * Getting "extra exports" of a given module.

Ah, obviously...  I can trace the reason I didn't see these as obvious
cases to the same little dependency graph I wrote about earlier:

  sub-`module*'  ⇢  module  ⇢  sub-`module'

Looks like the above items would all be on the left `module*' side,
and on that side it makes sense for the submodules on that side to be
public since otherwise there's no use for them.  So maybe there's a
case for `module*' to be visible and for `module' to be hidden?

I can't think of practical cases where a submodule on the right side
should be visible to the outside.  Hopefully this will be clear: for a
sub-`module' to be visible on the right, it needs to have some excuse
for being a sub-`module', but since there's no way to require the main
module from these sub-modules, I no reason for them to be
sub-`module's rather than sub-`module*'s.  IOW, I think that even a
"code-repository" kind of thing could be done with sub-`module*'s.


> > I first thought that the whole point of allowing a sub-`module'
> > would be to have some otherwise-inaccessible private code in it
> > (as the fictitious author of that `my-code' module thinks).
> 
> That is indeed not the goal. But it works the other direction with
> `(submodule* ... #f ....)': the enclosing module can have
> otherwise-inaccessible code that is accessed by the submodule (e.g.,
> to test unexported functions).

(This sounds like a point that supports what I said above.)


> > If that's wasn't possible, or possible only as a some
> > semi-obscure-reflection-api then the `submod' syntax could be
> > simpler.
> 
> I'm not sure what you mean here.

(I was talking about not allowing submodules to be visible.
Clarifying the above first would help here, probably.)


> > > > I also love the analogy to paths -- but using strings for them
> > > > doesn't look so nice, since strings are begging to be
> > > > combined...  (I can already see myself wishing for
> > > > "./../foo".)  Other than the obvious reader issue, would there
> > > > be a problem in using `|.|' and `..' for these (and making
> > > > them into special module names)?
> > > 
> > > Submodule identifiers are not currently constrained, and I think
> > > we should avoid constraining them. If we refrain from
> > > constraining submodule names, then `..' could be the name of a
> > > submodule.
> > 
> > It just seems similar to the old ("lib.ss" "some" "path") thing in
> > that it's asking to be changed to something that is easier to
> > remember.  Maybe make ".." have an implicit "." before it so
> > there's no need for a mysterious `"." ".."'?
> 
> Yes, I think `(submod ".." <elem> ...)' can be a shorthand for
> `(submod "." ".." <elem> ...)'. I see no way to handle it other than
> as a special case, but that seems ok.

The main benefit I see in this is to supress the "obvious" desire to
combine them with "./..".

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!