At Fri, 9 Mar 2012 16:35:25 -0500, Eli Barzilay wrote:
> Two days ago, Matthew Flatt wrote:
> >
> > Given the term "submodule", the first thing that you're likely to try
> > will work as expected:
> >
> > #lang racket/base
> >
> > (module zoo racket/base
> > (provide tiger)
> > (define tiger "Tony"))
> >
> > (require 'zoo)
> >
> > tiger
> >
> > Within `module', a module path of the form `(quote id)' refers to
> > the submodule `id', if any. If there's no such submodule, then
> > `(quote id)' refers to an interactively declared module, as before.
>
> This is *really* nice in how it's building a scope for module names,
> but OTOH, it makes the quote seem more like a syntactic hack...
Agreed.
> > [...later...]
> >
> > (require (submod 'zoo monkey-house))
> >
> > [...] a shorthand for `(submod "." zoo)' [...]
>
> ...especially here -- why is there a quote only on the first and not
> on the second?
That jumped out at me, too. But the first is a module path and the
second is a submodule name. For example,
(submod zoo monkey-house)
would mean the `monkey-house' submodule of "main.rkt" from the "zoo"
collection, not a `monkey-house' subsubmodule in a `zoo' submodule.
> Is there any meaning for (submod foo) without the
> quote (or a sting)?
We could allow
(submod foo)
as equivalent to
foo
that is, as a reference to `foo' with an empty submodule path.
> Perhaps a more obvious question is why aren't all `submod' uses get
> "." as an implicit first expression?
I don't see how lets you reach a submodule from the top level or from
within a different top-level module.
> > The 'zoo module path above is really a shorthand for `(submod "."
> > zoo)', where "." means the enclosing module and `zoo' is its
> > submodule. You could write `(submod "." zoo monkey-house)' in place
> > of `(submod 'zoo monkey-house)'.
>
> 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.
> How about just (submodule foo ...) be a more
> memorable syntax for (module* foo #f ...)?
That was Jon's suggestion, and my objection is that "submodule" means
something more general than those nested modules that are declared with
`submodule'.
> taking what Jay did (I think, didn't look at the code or the
> followups, yet), and making this:
>
> (submodule <name> E ...)
>
> be something that can appear anywhere in the code, expands to what
> (module* main #f E ...) is doing now, *and* is allowed to be used more
> than once, with all uses being collected into a single submodule.
Yes, I think this is a promising direction, and we just need to find a
better name than `module**'. I'll leave that discussion to the other
subthread.
> > The `#lang' reader form was previously defined as a shorthand for
> > `#reader' where the name after the `#lang' is mangled by adding
> > "/lang/reader". With submodules, `#lang' first tries using the name
> > as-is and checking for a `reader' submodule; if it is found, then
> > the submodule is used instead of mangling the name with
> > "/lang/reader", otherwise it falls back to the old behavior.
>
> (BTW, there's an obvious question here of why not do that for all
> paths, so that `foo/bar/baz' can access a `bar/baz' submodule in `foo'
> or a `baz' in `foo/bar'...
Search paths cause lots of trouble and should be avoided when possible.
This particular two-step search seem to be just barely tolerable for
`#lang', and I still worry about it; I wouldn't suggest it if I saw a
better way to accommodate existing code.
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
