Hi, 2011/6/21 Simon Peyton-Jones <simo...@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:j...@cs.uu.nl] > *Sent:* 21 June 2011 09:01 > *To:* Simon Peyton-Jones > *Cc:* David Mazieres expires 2011-07-21 PDT; o...@okmij.org; > ccs...@rutgers.edu; Dimitrios Vytiniotis; haskell-prime@haskell.org > > *Subject:* Re: TypeFamilies vs. FunctionalDependencies & type-level > recursion**** > > ** ** > > Hi,**** > > 2011/6/21 Simon Peyton-Jones <simo...@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**** > > ** ** >
_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
