Hi,

2011/6/21 Simon Peyton-Jones <simonpj@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 (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@cs.uu.nl]
Sent: 21 June 2011 09:01
To: Simon Peyton-Jones
Cc: David Mazieres expires 2011-07-21 PDT; oleg@okmij.org; ccshan@rutgers.edu; Dimitrios Vytiniotis; haskell-prime@haskell.org


Subject: Re: TypeFamilies vs. FunctionalDependencies & type-level recursion

 

Hi,

2011/6/21 Simon Peyton-Jones <simonpj@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