Craig Dickson wrote:
>Johannes Waldmann wrote:
>
>>i'd like to support Ralf's opinion: n+k patterns have advantages
>>(when used in a certain manner) so it would be good to keep them.
>>
>>personal reason: right now i'm busy giving tutorials on recursive functions
>>and it's really nice if you can write f(...,y+1) = ... (... y)
>>instead of f(...,y) = ... (... y-1)
>
>Why do you find this makes a significant difference? Personally, I find
>
> f x = ... f (x - 1)
>
>much more intuitive than
>
> f (x + 1) = ... f x
>
>I see no advantage in the n+k version.
Well, I find the n+k version more intuitive, but I hate n+k patterns. Haskell goes to
so much trouble to distinguish type variables from type constructors, and pattern
variables from data constructors, and infix operators from prefix operators, and then
it does a 360 by insisting that "+" is going to act as a constructor in this very
special case.
Actually, I'm a little surprised that people tout this construction as a teaching aid.
Yes, it makes the important connection between functions defined over numbers and
functions defined over algebraic datatypes. But at the same time it blurs the equally
important (in Haskell, at least) distinction between data constructors and functions
over datatypes. Don't you find that people exposed to this programming style end up
writing things like
sort (xs ++ ys) = sort xs ++ sort ys
...
?
--FC
