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

Reply via email to