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.
