On 12-Nov-1998, D. Tweed <[EMAIL PROTECTED]> wrote:
> 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.
Yes, and likewise vice versa (inserting a 5-tuple into a list of 3-tuples).
> 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)?
The dictionaries should get created only if they might be used,
i.e. only if you pass an n-tuple to a function such as the
above `sort' function which has type `hasFst t => ...'.
So I don't think it would lead to efficiency problems.
--
Fergus Henderson <[EMAIL PROTECTED]> | "Binaries may die
WWW: <http://www.cs.mu.oz.au/~fjh> | but source code lives forever"
PGP: finger [EMAIL PROTECTED] | -- leaked Microsoft memo.
