TypeFamilies vs. FunctionalDependencies & type-level recursion

[Simon Peyton-Jones]

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: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<mailto: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/f6644c86/attachment-0001.htm>