Jan de Wit wrote: > > On Sat, 2 Oct 1999, Matt Harden wrote: > > [snip] > > > > I like that, but I wish we had a way to get the "head" and "tail" of > > tuples, just as we do with lists, and combine them. Maybe a (:,) > > operator that works like this: > > > > a :, (b :, ()) = (a,b) > > a :, () = UniTuple a > > a :, (b,c) = (a,b,c) > > a :, (UniTuple b) = (a,b) > > > > Also allow pattern matching on this operator. > > > [snip] > > > > This seems a little too obvious to me. Has it been suggested and shot > > down before? > > > > Matt Harden > > > Well, you can define a class Splittable: > > class Splittable a b c where > spl :: a -> (b,c) -- split tuple > lps :: (b,c) -> a -- reverse split > > With fairly obvious instances for Splittable a a (), Splittable (a,b) a b, > Splittable (a,b,c) a (b,c) etc. The only problem with this kind of solution > is that when you type, e.g. spl (3,4,5), hoping to obtain (3,(4,5)), hugs > complains with: > ERROR: Unresolved overloading > *** Type : (Num a, Num b, Num c, Splittable (c,b,a) d e) => (d,e) > *** Expression : spl (3,4,5) > Yes, I have been thinking of almost the same thing, except I would not have any arbitrary (x) be a 1-tuple (unituple? monotuple?), because then what is ((x,y))? A 1-tuple, or a 2-tuple? Also, under your scheme, spl (x,(y,z)) = spl (x,y,z) = (x,(y,z)) ... which for some reason bothers me a lot. That's why I use a UniTuple datatype above. Btw, the user would almost never actually *encounter* a UniTuple. Certainly zip', show, read, etc. can be defined without using it. Another option would be a class that converts tuples to/from a "cascading pair": cascade (a,b,c) = (a,(b,(c,()))) cascade () = () cascade (a,b) = (a,(b,())) uncascade (b,()) = UniTuple b -- or this can be undefined The un/cascade scheme allows us to avoid 1-tuples altogether. Of course un/cascade and spl/lps can be defined in terms of one another. Btw. I still would want the compiler/interpreter to auto-generate these class instances for all tuples the way it currently does for Eq, Ord, Show, Read, Ix, etc... The nice thing is, instances of those classes can be created in terms of Splittable (or it's equivalent). Same goes for Zippable, of course, and I can think of more uses. > However, it seems that Mark Jones has an extension to Hugs in the works > where you can specify that the types b and c in the class depend on a, > which would resolve this issue. See http://www.cse.ogi.edu/~mpj/fds.html > for details - I really hope the September release comes quickly !!! I'll look at the extension. It seems to be sorely needed. Without it, I can't figure out a way to define Zippable (or Eq, Ord, etc.) in terms of Splittable. Can you? > Bye, > > Jan de Wit > Thanks Matt
