Re: n+k patterns

1993-05-19 Thread marc
From my point of view (n+k)-patterns have a very special meaning. This natural numbers should be considered as a type like this: data Nat = Zero | Succ Nat Therefore a (n+k)-pattern is an abbreviation for Succ(Succ(...Zero...)). It's obvious that "+" in "(n+k)" doesn't mean a somewhere else

Re: Successor patterns in bindings and n+k patterns

1993-05-19 Thread kh
And now for a little quiz. What's the value of the following (legal) Haskell expression? (Don't try it with hbc, it fails.) let (+) + 1 + 1 = (+) in 1 + 1 Given infixl 6 + (since you can't change this without renaming!): (+) + 1 + 1 == lpat6 + pat7

Re: Successor patterns in bindings and n+k patterns

1993-05-19 Thread hudak-paul
And now for a little quiz. What's the value of the following (legal) Haskell expression? (Don't try it with hbc, it fails.) let (+) + 1 + 1 = (+) in 1 + 1 This is illegal syntax!! (+) and (the second) + are the same variable, thus violating the linearity constraint for

Re: Successor patterns in bindings and n+k patterns

1993-05-19 Thread smk
Another strange thing about n+k patterns. Its definition uses = , but = is not part of the class Num. Does that mean that n+k patterns have to be instances of class Real? One could leave it class Num, if the translation were expressed in terms of "signum" rather than "=". Question: Can one

Re: Successor patterns in bindings and n+k patterns

1993-05-19 Thread Joe Fasel
| Another strange thing about n+k patterns. | | Its definition uses = , but = is not part of the class Num. | Does that mean that n+k patterns have to be instances of class Real? Certainly. In fact, they're really meant to apply only to class Integral (and it would be natural numbers, if we