On Fri, 13 Nov 1998, Fergus Henderson wrote:
> > It would
> > avoid the nastiness of a special definition for each tuple type and and
> > lead to more flexibility.
>
> I want each tuple arity to be a different type, so that I get a compile
> error rather than a run-time error if say I pass a 3-tuple to a
> function expecting a 4-tuple.
There's two levels of type knowledge leading to safety here though.
If I've got a function that's supposed to be calculating some clever
statistics on a list of 5-tuples (say) then I want a type error to tell me
if I've somehow managed to bung a 3-tuple onto the list.
But there if I've got a function that sorts a list of tuples based on
their first component (and pretending sort & sortBy don't exist) then I
might do a quicksort based thing such as
sort [] = []
sort (x:xs) = sort [y | y<-xs,fst y<fst x] ++ [x]
++ sort [y | y<-xs,fst y>fst x]
and here all I care about is that its meaningful to grab the first
element, which should be the same as having a fst defined on the type.
So isn't it just something that we want to create an group of typeclasses
such as hasFst, hasSnd, hasThd, ... that can be used with existential
types. Am I missing some way in which making fst, snd into methods for
these classes would lead either to type-safety problems or efficiency
problems (every n-tuple seems to need to carry around at least n
dictionaries)?
___cheers,_dave_________________________________________________________
email: [EMAIL PROTECTED] "I'm guilty of a lot of things but I've
www.cs.bris.ac.uk/~tweed/pi.htm never violated the law of conservation
work tel: (0117) 954-5253 of energy!" -- Bart Kosko, Nanotime
