On 14/09/2011, at 1:44 PM, Chris Smith wrote:

On Wed, 2011-09-14 at 13:35 +1200, Richard O'Keefe wrote:

...

I would like to have

tuple (f1,f2) x = (f1 x, f2 x) tuple (f1,f2,f3) x = (f1 x, f2 x, f3 x)

There is no polymorphism across tuple structures,

I know that. I know how tuples get to be instances of Ix, one instance declaration for each of (,) (,,) (,,,) ....

so if you absolutely *must* have n-tuples instead of nested 2-tuples, then you just need to implement the new functions as needed. You can't implement that only once.

I don't *expect* to implement anything just once. I am perfectly happy writing as many instance declarations as I have tuple sizes that I care about. It's just that I can't see how to get the types right, because in class Thingy t ... where tuple :: t -> a -> b b depends on t and possibly a, so instance Thingy (,,) where tuple (f,g,h) x = (f x, g x, h x) it's not an arbitrary b. Can this be done with functional dependencies?

On Tue, Sep 13, 2011 at 10:03 PM, Chris Smith wrote:

Ah, okay... then sure, you can do this:

class Tuple a b c | a b -> c where    tuple :: a -> b -> c

instance Tuple (a -> b, a -> c) a (b,c) where    tuple (f,g) x = (f x, g x)

This wouldn't actually work well in practice. There's no dependency between the various occurrences of "a" in the types, so unless they're already known to be the same, GHC will complain about an ambiguous instance (please excuse the silly GHCi prompt): Ok, modules loaded: Tupling. ∀x. x ⊢ tuple ((+3), show) 4 <interactive>:0:1: No instance for (Tuple (a0 -> a0, a1 -> String) b0 c0) arising from a use of `tuple' Given that the class is only intended to be used where those types are equal, you really want it to unify them based on use of the tuple function.

and so on...  You'll need fundeps (or type families if you prefer to write it that way), and probably at least flexible and/or overlapping instances, too, but of course GHC will tell you about those.

I rather prefer type families in this case, both because the problem is easily expressed in "type function" style, and because it gives you an easy type equality constraint to use, rather than using arcane trickery with overlaps to force post-hoc unification. We'd probably want to do something like this: class Tuple t where type Arg t :: * type Result t :: * tuple :: t -> Arg t -> Result t instance (x1 ~ x2) => Tuple (x1 -> a, x2 -> b) where type Arg (x1 -> a, x2 -> b) = x1 type Result (x1 -> a, x2 -> b) = (a, b) tuple (f, g) x = (f x, g x) instance (x1 ~ x2, x2 ~ x3) => Tuple (x1 -> a, x2 -> b, x3 -> c) where type Arg (x1 -> a, x2 -> b, x3 -> c) = x1 type Result (x1 -> a, x2 -> b, x3 -> c) = (a, b, c) tuple (f, g, h) x = (f x, g x, h x) Used like so: Ok, modules loaded: Tupling. ∀x. x ⊢ tuple ((+2), show, (< 2)) 3 (5,"3",False) Note that not only does this avoid ambiguity, it even unifies ambiguous types that are then defaulted by the usual means. That said, I question the utility of a class like this. The boilerplate instances are tedious to write and it's not flexible in any way; tuples not being defined inductively makes them a real pain to work with unless there's a particularly good reason to do so. Something equivalent to right-nested (,) with () as a terminator is much more pleasant, and since we're deep in the pits of non-portability anyway, might as well pull out bang patterns and UNPACK pragmas if avoiding extra bottoms was the reason for using plain tuples. - C.

On Wed, Sep 14, 2011 at 9:32 AM, Victor Nazarov wrote:

I've just tried another approach (code below). And GHC even inferred type for tupleF. But I think GHC inferred the wrong type and I can't formulate the right one, it seems to require infinite number of constraints. With GHC inferred type this function is not usable, though:

GHC can't actually infer your type with that implementation of tcons. There's no way for it to get from the arguments "THead t" and "TTail t" to the tuple type t, because (unlike type constructors) type families aren't necessarily injective, so there could be more than one type "t" that THead and TTail map to the types received. Furthermore, the open world assumption for type families means that even if there's only one valid "t" in scope, it can't simply select that because it must account for the possibility of more instances being introduced in other scopes. On the other hand, it can get from "t" to "THead t" and "TTail t" just fine, so if you give a type annotation that fixes the result type it should work. But that can be clumsy for actual use. The above issue is exactly why the implementation that I gave uses a slightly peculiar approach to calculate the other types based only on the type of the tuple argument. A slightly more complicated approach could probably be used to get some inference going in both directions, but in most cases the direction I gave will be what you want most. That said, the essential idea of what you're trying to do is a good one. Why not try separating the steps, though? Use one type family to give a bijection between standard tuples and some sort of right-nested pair representation (which is easy to infer both ways), then use standard type-level recursion to process the latter form however you like. You can do generic equivalents of map, fold, zip, &c. this way pretty easily. - C.

Using fundeps I came up with this: class T funs arg res | funs -> arg res, arg res -> funs where tuple :: funs -> arg -> res instance (a ~ a0, a0 ~ a1) => T (a0 -> b, a1 -> c) a (b, c) where tuple (f, g) a = (f a, g a) instance (a ~ a0, a0 ~ a1, a1 ~ a2) => T (a0 -> b, a1 -> c, a2 -> d) a (b, c, d) where tuple (f, g, h) a = (f a, g a, h a) Intuitively it seems to be exactly the same as the type families' aproach, and looks quite clear too. On 9/15/11, Richard O'Keefe wrote:

On 14/09/2011, at 2:45 PM, Casey McCann wrote:

...

class Tuple t where type Arg t :: * type Result t :: * tuple :: t -> Arg t -> Result t

instance (x1 ~ x2) => Tuple (x1 -> a, x2 -> b) where type Arg (x1 -> a, x2 -> b) = x1 type Result (x1 -> a, x2 -> b) = (a, b) tuple (f, g) x = (f x, g x)

That's it, that's what I was after. Thanks.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Markus Läll