(I sent this before, but it didn't seem to get through. Sorry if
it's a repeat for anyone.)
-------------
More on (n+k) patterns. (I'm inflamed!) In response to JL's latest:
> The problem is only partly to do with naturals. Having these would
> certainly improve matters but I suspect the Num class is big enough
> already.
If it can be big enough to include rational numbers and floating
point approximations to complex numbers, surely it can be big enough
to include the naturals. The former may have rarity value, but the
latter are used (presently under trying circumstances such as the n+k
botch) in almost every Haskell program.
> some other problems of (n+k) patterns are
> * syntax: + is the only nonconstructor constant allowed in patterns.
This anomaly is just a consequence of another: numbers are the only
types with arbitrarily many constant constructors instead of a small
number of recursive ones. For the naturals, of course, +1 can be just
a convenient postfix shorthand for the successor constructor.
> * generality: mathematics commonly uses (bn+k) patterns, but Haskell doesn't
> allow this. It has one series of special cases only.
But this argument could be applied equally to other types, both numeric
and non-numeric. Remember the earlier proposal for view mappings
allowing, for example, complex number patterns to use polar or
cartesian form? Dropping views did not also lead to dropping the
complex numbers, did it? Besides, doesn't Peano distinguish +1 as a
special case -- a constructor indeed? (I'm not too bothered about n+k,
as opposed to n+1, though it seems a handy enough shortform.)
> * construction: laws were thrown out of Miranda because of the confusion
> created when something built one way, was taken apart another way. All our
> patterns *except (n+k)* have the property that the deconstruction reverses
> construction. If I build (a:as) then take it apart with pattern (x:xs) then
> x is a, and xs is as. If I build (a+b) then take it apart with pattern
> (n+1) then I cannot deduce that n is a (nor that 1 is b).
If +1 were indeed a constructor, your objection would be partly
answered. (I don't want to get side-tracked into the ``strict
constructors'' debate here!) The rest is just a question of taste in
lexical overloading. As before, the anomaly can just as easily be
cast the other way round: all our recursive functions over data types
*except numbers* naturally follow their recursive structure. So
structural induction is OK, but natural induction is too hard?
And LA writes (about n+k):
> Let's get rid of this horrible wart once and for all. It's a special
> case that makes the language more difficult to explain and implement.
> I've hardly seen any programs using it so I don't think backwards
> compat is a problem.
I agree that n+k patterns for the integer types, as presently defined,
are an oddity and should go. But surely the reason they arose in the
first place was a recognition of the fact that most programming is done
with integers just because they are the nearest thing there is to the
naturals. Bolting on a special case rule is not a sufficient
recognition of this fact. Get rid of n+k ``once'' (for integers) but
not ``for all''. Natural numbers should be First Class Citizens!
Colin R
