Changes between Version 17 and Version 18 of ViewPatterns


Ignore:
Timestamp:
Jan 25, 2007 11:13:24 AM (8 years ago)
Author:
guest
Comment:

migrating pros and cons to the features

Legend:

Unmodified
Added
Removed
Modified
  • ViewPatterns

    v17 v18  
    308308Here the first argument `p` can be thought of as a pattern passed to `g`, which 
    309309is used to match the second argument of `g`. 
     310 
     311Here is another rather cute example: 
     312{{{ 
     313unfoldr :: (b -> Maybe (a, b)) -> b -> [a]  
     314unfoldr f (f -> (a, b)) = a : unfoldr f b 
     315unfoldr f other         = [] 
     316}}} 
    310317 
    311318=== Implicit `Maybe` feature === 
     
    346353    f (prodSize -> Big)    = ... 
    347354}}} 
     355Using a fixed set of multiple alternatives makes it more obvious whether the match is exhaustive or not. 
    348356 
    349357While the implicit `Maybe a` is more compositional and nicely integrates with already existing uses of the `Maybe`-type, it cannot share expensive computations across multiple alternatives. This is a strong argument against the implicit `Maybe a`. To illustrate the problem, suppose that 
     
    380388 
    381389The problem that needs to be solved is to introduce abstraction "after the fact". 
     390 
     391On the other hand, view patterns can do arbitrary computation, perhaps expensive. So it's good to have a syntactically-distinct notation that reminds the programmer that some computation beyond ordinary pattern matching may be going on. 
    382392 
    383393=== Nesting ===