This is similar to what I want to see, but I didn’t have the restriction that developers should only be able to export functions that reference owned/hard/contained/user types, but rather, that they don’t require an explicit “import” to be able to extend that name (which basically makes it impossible to develop code in isolation…)
I thought the compiler could tell that fact rather easily (i.e., if the function being exported referenced at least one “owned/contained/user type”), but if that’s not so, it could still be solved by having the develop explicitly indicate that that is the case… Maybe instead of export, use a different keyword, or an option on export, to indicate that. If that keyword or option is used, then the system should go ahead and do an automatic merge if somebody does “using”. > On Apr 29, 2015, at 1:54 PM, Stefan Karpinski <[email protected]> wrote: > > On Wed, Apr 29, 2015 at 1:01 PM, Michael Francis <[email protected] > <https://mail.google.com/mail/?view=cm&fs=1&tf=1&[email protected]>> > wrote: > I made the point at the outset that it isn't hard (or expensive) if the > exported functions from a module must reference types defined in that module. > Hence the suggestion that module developers should only be able to export > functions which reference owned/hard/contained/user types. > > Unless I'm misunderstanding, this is a very limiting restriction. It would > mean, for example, that you can't define and export a generic > square(::Number) function. That's a silly example, but it's completely > standard for packages to export new functions that operate on pre-existing > types that don't dispatch on any type that "belongs" to the exporting module. > > Another way of looking at this is that such a restriction would prevent > solving half of the expression problem > <http://en.wikipedia.org/wiki/Expression_problem>. In object-oriented > languages, extending existing operations to new types is easily done via > subtyping, but adding new operations to existing types is awkward or > impossible. In functional languages, adding new operations to existing types > is easy, but extending existing operations to new types is awkward or > impossible. Multiple dispatch lets you do both easily and intuitively – so > much so that people can easily forget why the expression problem was a > problem in the first place. Preventing the export of new functions operating > only on existing types would hobble the language, making it no more > expressive than traditional object-oriented languages. Preventing the export of new functions because they accidentally happen to have a name conflict (not because of an actual signature conflict) is also a very significant hobble to the language… I think the language needs better tools to be able to be able to develop packages independently, while still allowing all the goodness of extending base, or other packages, as well as ways of keeping the interface and implementation separate… (this goes back to what I learned from CLU… how important it was to be able to keep those separate, so that people can’t abuse your internal data structures…) Julia is *way* too lax in that… I can look at the string types internal information, for example, and that ends up tempting people to bypass the abstraction, which then means major breakage when you want to change things to improve something... Scott
