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. 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<mailto: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
