[Haskell-cafe] Increasing Haskell modularity

[Richard Eisenberg]

I'm against this proposal.

* I'm not sure exactly what you mean by "adopt [Oleg's] proposal". What's the proposal? I'm familiar with the reify/reflect trick (see http://hackage.haskell.org/package/reflection) but don't see how that exactly relates to the issue at hand. It seems the first part of your proposal just says "Haskellers can no longer expect class instance coherence." As such, this is a drastic change that would require all Haskell programs to be inspected to see if they crucially rely on coherence.

* As for associated vs. non-associated type families: There is essentially no difference between associated and non-associated type families, save concrete syntax. If the Haskell house were on fire and we needed to eliminate one of these forms, I would agree to it without much trouble, because the two forms are equally expressive.

But, eliminating non-associated type families wouldn't solve your problem at all: while class instance incoherence causes wonky runtime behavior, associated type instance incoherence breaks the type system. If I understand your proposal correctly, users could implement unsafeCoerce through clever hackery around associated type instance incoherence. This seems to be against the Haskell tradition of strong typing.


I agree that the non-modular state we're in is regrettable. There may be a way out of the hole, but I don't think this proposal is it.

Richard

On Oct 1, 2014, at 9:14 AM, Gesh <gesh at gesh.uni.cx> wrote:

> 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
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>