- the type checker to always typecheck both alternatives, which can't be done!
- This is a fundamental problem, that would seem perfectly suited for a type
- class. Considering that we need to switch between to implementations of the
- sum function, based on the type of the argument, this sounds like the
- perfect problem to solve with a type class. However, this approach has its
- own problems (not the least of them that you need to define a new typeclass
- for every recursive function you want to define).
-
- Another approach tried involved using GADTs to be able to do pattern
- matching on empty / non empty lists. While this worked partially, it also
- created problems with more complex expressions.
-
- \note{This should reference Christiaan}
-
- Evaluating all possible (and non-possible) ways to add recursion to our
- descriptions, it seems better to leave out list recursion alltogether. This
- allows us to focus on other interesting areas instead. By including
- (builtin) support for a number of higher order functions like map and fold,
- we can still express most of the things we would use list recursion for.
-
- \todo{Expand on this decision a bit}
-
+ the type checker to always typecheck both alternatives, which can't be
+ done! The typechecker is unable to distinguish the two case
+ alternatives (this is partly possible using \small{GADT}s, but that
+ approach faced other problems \todo{ref christiaan?}).
+
+ This is a fundamental problem, that would seem perfectly suited for a
+ type class. Considering that we need to switch between to
+ implementations of the sum function, based on the type of the
+ argument, this sounds like the perfect problem to solve with a type
+ class. However, this approach has its own problems (not the least of
+ them that you need to define a new typeclass for every recursive
+ function you want to define).
+
+ \todo{This should reference Christiaan}
+