# Re: n+k patterns

Original-Via: uk.ac.st-and.cs; Wed, 6 Nov 91 14:54:59 GMT

> > |       Kent Karlsson asks:
> > | | Which semantics did you use?
> > |
> > | The following seemed sensible to me (Your first choice in each case):
> >
> > [ ... my attempt at a semantics for c*p and p+k patterns ... ]
> >
> >    I had hoped not, since then a match can fail and fail the entier program,
> > even if a "later" patterns really matches, since in the above the "next"
> > pattern is not tested upon such a fail.
>
> I have been persuaded and would go along with Kent's proposed semantics
> for c*p and p+k patterns if these were introduced into the language.
> Specifically:
>
> |          case e0 of {p+k -> e; _ -> e'}
> | either   = if e0 >= k then case e0-k of {p -> e; _ -> e'} else e'
> | or       =                 case e0-k of {p -> e; _ -> e'}
>
> But let's not use the second option here ... I'm a firm believer that (p+k)
> patterns should match only positive values.
>
> Note also that this includes the current semantics for Haskell n+k patterns
> as a special case (writing p as a variable which is guaranteed to match and
> simplifying the case expr on the rhs).
>
> |          case e0 of {c*p -> e; _ -> e'}
> | either   = if e0 >= 0 then case e0 `divRem` c of (p, 0) -> e; _ -> e'} else e'| or
>      =                 case e0 `divRem` c of (p, 0) -> e; _ -> e'}
>
> The choice here isn't so clear.  Should c*p patterns match only positive
> values (for uniformity with with p+k patterns, although there is no real
> need for the restriction in this case), or should we allow them to match
> arbitrary multiples of c?  Perhaps someone with lots of examples of the
> use of c*p+k patterns could comment on which would be best?  Tony?
>
> Thanks to Kent for straightening this out.
>
> Mark
>

I would be very much in favour of missing out the >= test in both n+k and
c*n+k. As Mark says there is no need for a restriction in the latter case.
In the former, the restriction is only there because of a wish to model
the Natural Numbers, a data type which is NOT native to Haskell.

Tony