I would find something like this very useful, but similar to what Eli mentioned it would strongly encourage exposing subcollections and submodules which leads to inflexibility. Additionally, having directories, files, and submodules shadow each other in some defined order could lead to tricky to track down bugs. It might be better for an ambiguous require to be an error, or at least a warning.
On Sunday, July 5, 2015 at 10:27:35 PM UTC-7, Alexis King wrote: > > Exposing submodules is becoming more prevalent in Racket, and I think that > may > be a good thing. The downside is that the syntax for requiring a submodule > outside of its defining module is a bit clunky (the use of `submod` is > necessary). The same would be true for `lib`, but Racket already has sugar > for > `lib` in the form of symbolic module paths, which is obviously the most > common > way to specify modules. > > Since the grammar for these paths already constrains the characters they > may > contain, it would be completely feasible to add a little more sugar to > make > requiring submodules easier. To make this more concrete, something like > (require foo/bar:baz) could be equivalent to (require (submod foo/bar > baz)). > > I, myself, have two main thoughts about this, having already considered it > somewhat. > > 1. I think this would elevate submodules to a more commonly-used > feature. > Right now, aside from main and test submodules, they rarely pop up, > mostly > because there’s little need most of the time, and using them is > verbose. > However, since modules themselves are intrinsically tied to the > filesystem, > sometimes it’s nice to not need to create a full module. > > 2. There is a downside to this (aside from the obvious potential > downside of > cluttering the module path with more syntax): it makes it much easier > to > expose submodules as part of a public API, but still forces the > consumer > of a module to be aware of the difference between a module and a > submodule. > > This means that a user needs to remember if a module path is foo/bar > or > foo:bar, depending on whether or not the author used a submodule, and > it > also means there is not a seamless path for moving a submodule to a > full > module or vice-versa. > > The above caveat is real, but I still think it could be advantageous all > the > same. Thoughts? Questions? Concerns? > > Alexis > > -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/d4007c6e-9357-4388-b316-1d903da205ce%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
