4

In the introductory text for Template Haskell one of the examples for why Template Haskell is useful is working with arbitrary sized tuples.

What is the purpose of arbitrary sized tuples? If the data type is the same why not use a list? And if the data types in the tuple are different, how can it be expanded to arbitrary sizes?

Willem Van Onsem
  • 443,496
  • 30
  • 428
  • 555
user668074
  • 1,111
  • 10
  • 16
  • I feel the need to mention [the "tuple-th" library](http://hackage.haskell.org/package/tuple-th), which I've found very useful in my practice. – Nikita Volkov Jan 14 '16 at 12:28

1 Answers1

12

With arbitrary one means arbitrary at compile time. So if you want tuples with fifteen elements, template Haskell will generate a function for a tuple with fifteen elements. After compilation however, the number of elements is fixed. The advantage of using a tuple is that you can access each element in constant time O(1). So you can use the type system to enforce the tuple still contains a fixed amount of elements.

Furthermore the sel in the example can work with tuples where the elements have arbitrary types. For instance sel 2 3 will generate a function:

$(sel 2 3) :: (a,b,c) -> b
$(sel 5 5) :: (a,b,c,d,e) -> e

whereas if you use a list [a], this means that the list can only contain data for a certain type:

(!!3) :: [a] -> a

so all items have type a. Furthermore in this case you are not sure that the list will have three elements. The more you can check at compile time, the more safe your code is (and in many cases more efficient as well).

A list on the other hand has an arbitrary size at runtime. The same type - for instance [Int] - can specify a list with two, five, hundred or thousands of integers. Furthermore in the case of a list, accessing the k-th element requires O(k) time. There are datastructures like arrays that of course can access elements in constant time.

Willem Van Onsem
  • 443,496
  • 30
  • 428
  • 555
  • Wouldn't one be better off using a new data type though? Like `data X = A Int | B Char | C String` or something along this line? – Akaberto Jan 14 '16 at 13:38
  • @Akaberto: I wouldn't advocate for this for several reasons: (a) as said before, the compiler cannot do much typechecking which can solve many problems, (b) the number of types is endless, and one should thus need to learn what `A`, `B`,... means (c) what will you do with polymorphic types (d) it is more inefficient as it implies another indirection,... – Willem Van Onsem Jan 14 '16 at 13:40
  • Oops, I meant something like `data Person = Person { firstName :: String, lastName :: String, age :: Int }` Isn't this similar to a tuple? – Akaberto Jan 14 '16 at 13:56
  • Also, with the above (a) should be handled by the type checker, (b), while the number of types are indeed endless, you would still know what you are dealing with (perhaps even more so with record types as you can name the fields explicitly). (c) can be handled via type constructors and isn't (d) present in tuples too (or are they optimized to avoid an indirection). Even with that, is it worth the trouble to use arbitrary tuples? – Akaberto Jan 14 '16 at 14:01
  • 1
    @Akaberto, it's the same. But when generating source with TH, you likely don't have meaningful names to use, or know how many fields you have to deal with. – dfeuer Jan 14 '16 at 14:05
  • @dfeuer: Oh, so it is useful when generating code. I have to read up on TH (been dodging it for a while now). Just skimmed through HaskellWiki's entry on TH and do see a lot of code involving tuples. Thanks. – Akaberto Jan 14 '16 at 14:21
  • @Akaberto: template Haskell has nothing to do with tuples itself. They only use it as an example. To put it bold: with template Haskell you write code that writes code for you. Compare it to templates in C++. The advantage is that if you do it properly, you are less likely to make errors, and code can be more compact. Instead of specifying an `instance Functor` for every tuple yourself, describe how such instance for a generic tuple would look like. – Willem Van Onsem Jan 14 '16 at 14:26