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.
