On Wed, Jan 10, 2007 at 03:27:40PM +0300, Bulat Ziganshin wrote:
Hello David,
Hi Bulat,
Wednesday, January 10, 2007, 5:35:03 AM, you wrote:
class List l e, l -> e where
(But I don't like functional dependencies, because they confuse me, and hope that associated types end up making it into Haskell'...)
well, it is pretty studied design space, you can look the chapter about fundeps in ghc 6.6 manual which describes various solutions for containers class problem
I understand the idea of fundeps, but not their limitations--and every time I've tried to actually use them (admittedly, always for something harder than this) those limitations have bitten me. And the answer always seems to be that the code is correct, but there are reasons (involving termination or decidability) that I don't understand, why the compiler can't accept my code. From what I've heard from Manuel, with AT (and indexed types in general) the restrictions are identical, but are far easier to explain to a naive programmer such as myself.
generally, we need either FD (which is not a part of Haskell') or AT (which is supported only by GHC HEAD)
Yes, and I'm rooting for AT. Since no two implementations support the *same* FD, the only issues are that AT is only supported by ghc HEAD rather than also being supported by a released ghc, and also that no existing code uses AT. But to me, the ease of understanding absolutely outweighs those issues, and it seems like a language feature that's easy for programmers to reason about should also be easier for implementors to get right. And I don't know if you're aware of this, but the current plans are for ghc to switch to implementing fundeps via a translation into AT, which apparently will significantly simplify ghc's code. Admittedly, this is partly just because the fundeps implementation predates system fc, and doesn't take advantage of it as AT does. -- David Roundy http://www.darcs.net