TypeFamilies vs. FunctionalDependencies & type-level recursion

[José Pedro Magalhães]

Hi,

2011/6/21 Simon Peyton-Jones <simonpj at microsoft.com>

>  I suppose that could be changed, yes, but what exactly are we trying to
> solve here? One can already specify different behavior for constructors
> with/without named fields. Are we trying to avoid OverlappingInstances? Then
> yes, this might help, but I'm not sure this change alone would make all
> generic programming possible without OverlappingInstances.****
>
> ** **
>
> To be clear, I wasn’t advocating a change, just saying that there’s no
> GHC-HQ imperative to avoid them.****
>

Ah, right. I would also be happy to help improving the current generics
mechanism.

Also, reading up on OverlappingInstances in the User's
Guide<http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#instance-overlap>(namely
the incoherence example without IncoherentInstances) made me see the
evilness of the current implementation. But I would only favor deprecating
OverlappingInstances when there is a clear alternative supporting (and
potentially improving) the current uses for OverlappingInstances.


Pedro


>
> Simon****
>
> ** **
>
> *From:* José Pedro Magalhães [mailto:jpm at cs.uu.nl]
> *Sent:* 21 June 2011 09:01
> *To:* Simon Peyton-Jones
> *Cc:* David Mazieres expires 2011-07-21 PDT; oleg at okmij.org;
> ccshan at rutgers.edu; Dimitrios Vytiniotis; haskell-prime at haskell.org
>
> *Subject:* Re: TypeFamilies vs. FunctionalDependencies & type-level
> recursion****
>
>  ** **
>
> Hi,****
>
> 2011/6/21 Simon Peyton-Jones <simonpj at microsoft.com>****
>
> | One thing you could do to help in this specific case would be to use a
> | different M1 tag--e.g., M1 S ... for selectors and M1 NS ... for
> | fields without selectors (or K1 NS).  I presume you've already
> | considered this and/or it's too late to make such a change.  (Or to
> | move the distinction up to the constructor with two different
> | constructor tags, CR and CN for record and no-record.)****
>
> I don't think it's too late to make a change.  The stuff has only just gone
> in, so it's still very malleable.  There may be other considerations, but
> legacy code isn't one of them!****
>
>
> I suppose that could be changed, yes, but what exactly are we trying to
> solve here? One can already specify different behavior for constructors
> with/without named fields. Are we trying to avoid OverlappingInstances? Then
> yes, this might help, but I'm not sure this change alone would make all
> generic programming possible without OverlappingInstances.
>
> (Also, I always thought UndecidableInstances were "more evil", in some
> sense, and this change does nothing to remove the use of
> UndecidableInstances for generic programming.)
>
>
> Cheers,
> Pedro****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-prime/attachments/20110621/ad29884b/attachment.htm>