At Sun, 5 Jul 2015 22:27:32 -0700, Alexis King wrote: > 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). [...] > > 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)).
Yes, that seems feasible to me. It would be nice if a shorthand could also cover relative-path references, too, but I don't see a way to do that (at least, not without creating further confusion between relative-path references and filesystem-path references). At Tue, 7 Jul 2015 12:24:49 -0400, Anthony Carrico wrote: > I wonder how much trouble it would cause if there was a unified syntax > which considered a directory as a (standardized) module. That would create lots of trouble, unfortunately. Search paths are painful in general. It may seem that a search shouldn't be that bad --- implemented once and for all in the module-name resolver, say. It turns, though, out that various tools need to implement the same search with slightly different constraints, such as the module searches in `raco make` or `raco exe` or conflict detection in `raco pkg`. Dealing with various search dimensions is one of the least-fun parts of building those tools, so I'm especially reluctant to add more. In contrast, module-path parsing and normalization is relatively easy to centralize. If a `foo/bar:baz` notation seems worthwhile to others, I'd be willing to give it a try. -- 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/20150727172239.C63AA6501CE%40mail-svr1.cs.utah.edu. For more options, visit https://groups.google.com/d/optout.
