[Haskell-cafe] Increasing Haskell modularity
Gesh
gesh at gesh.uni.cx
Wed Oct 1 13:14:49 UTC 2014
Dear Café,
Edward Yang recently wrote about the non-modularity of the current semantics
for typeclasses[0] and open type families[1].
Given these problems, we can either try to work around the problem, or
decide
whether these features are worth the problems.
The specific pair of proposals I am making are the following:
* Give up on global uniqueness of typeclass instances.
Oleg discusses adding local typclass instances without losing
coherence in his
reflection paper[2]. If we adopt his proposal, and weaken global
uniqueness of
instances to local uniqueness, we can then say that typeclass
instances in a
module are considered more local than imported instances, and therefore
override them.
Since instances will be locally unique, we don't have to pass around
dictionaries. Data types that expect globally unique instances, such
as Set,
will have to store dictionaries, however.
* Give up on non-associated open type families.
This I have researched less well, but it seems to me that these have
no use
case. Since one can make whatever instances one wishes for these type
families, one can't do anything useful with values of their instances.
In other words, values of type F a are morally of type (forall a. a).
Thus, the only way I can see these being useful is if anyone creating an
instance of the family must also provide functions that can work with
these
instances, which brings us back to the case of associated types.
As far as I can see, these two features are useless and impeding the
drive to
make Haskell more modular. Therefore, my questions for you are twofold:
* Is there a reason to keep these features?
* If not, why don't we drop them?
Awaiting your criticism and ire,
Gesh
[0] -
http://blog.ezyang.com/2014/07/type-classes-confluence-coherence-global-uniqueness/
[1] - http://blog.ezyang.com/2014/09/open-type-families-are-not-modular/
[2] - http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.112.7819
More information about the Haskell-Cafe
mailing list