To be clear, I didn't mean to imply that the (independent) method lookup
issue suggested in any way that the original module-related future was
invalid. Just that there were a few different things jumbled together
here.
Kyle and I have been discussing this offline a bit as well. Here's a
quick summary of the most salient points:
In my mind, there are two main things that would improve this situation.
In no particular order:
1) supporting a mode (ideally the default) in which a 'module use' would
be non-transitive. I.e., using a module Foo wouldn't also import all
the symbols from any modules that it uses at its global scope.
(This is something we've discussed for quite some time. I vaguely
recall that there were good reasons we didn't do it from the outset,
though I'm having trouble remembering what those reasons were
without doing more archeology. I worry a little bit that they had
to do with scoping of generics, which is a sticky issue that C++
also wrestles with. But even if that's the case, it seems like
there might be something better than the big hammer of transitive
module use in the common case).
2) Supporting capabilities to import only certain symbols from a module,
to exclude certain symbols, to rename them upon import, to declare
module-private symbols, etc.
(This is something that we've also discussed since the earliest days
of the language, and which used to appear in the language spec, but
at some point we deprecated it, primarily to narrow the gap between
what was specified and what was implemented -- not because we
thought it was important, just because it felt like getting the
parallel / locality / scalability concerns under control was the
more important thing for our success. Now that we're getting onto
firmer ground there, returning to these design questions seems
reasonable, particularly as they start to bite our developers and
users in confusing ways).
For the first issue, I'm curious whether David Iten remembers what the
challenges around transitive module use were better than I do. I'm also
curious whether Chris Wailes and Jeremy Siek have insights there.
For the second issue, I'm remembering that Jeremy Siek had a proposal out
to improve this at one point, but don't believe that anything more has
been done with it since then. Assuming nothing has, I think it would be
reasonable to have someone digest that proposal, along with Kyle's
references below (and Scheme seems like another language to consider) and
propose something that fits Chapel's style and philosophy.
> Python import/module system, much of this is very specific to how python
> works and can be skipped:
> https://docs.python.org/3/reference/import.html
>
> Go packages spec:
> http://golang.org/ref/spec#Packages
>
> Upcoming C++ modules:
> http://clang.llvm.org/docs/Modules.html#introduction
>
> Rust module system:
> http://static.rust-lang.org/doc/master/rust.html#modules
>
> -Kyle
------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
