I've wanted to do this AND Anthony's idea of having submodules/directories/files/etc all appear in a unified hierarchy
Jay On Tue, Jul 7, 2015 at 3:05 AM, Matthias Felleisen <[email protected]> wrote: > > An alternative would be to have named provide specifications. That way > we could tell one client to use API R and another client to use API TR to > access functions from our module. If we do this right, we can connect > submodules > to such provides and nobody will ever know that they are requiring a > submodule. > > -- Matthias > > > > > On Jul 6, 2015, at 7:27 AM, 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/5D260BC4-FA07-4668-919D-92A6B3DC9DB4%40gmail.com. >> For more options, visit https://groups.google.com/d/optout. > > -- > 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/2AD9E5E4-DB2C-4D9E-BE69-69C07A43BE4C%40ccs.neu.edu. > For more options, visit https://groups.google.com/d/optout. -- Jay McCarthy http://jeapostrophe.github.io "Wherefore, be not weary in well-doing, for ye are laying the foundation of a great work. And out of small things proceedeth that which is great." - D&C 64:33 -- 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/CAJYbDa%3DKSpiAhGfMaOmadY1b1XyYXWHxhWBeHREbyYaC23L%2BFg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
