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! _________________________ Racket Developers list: http://lists.racket-lang.org/dev