Changes between Version 17 and Version 18 of ViewPatterns


Ignore:
Timestamp:
Jan 25, 2007 11:13:24 AM (9 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 ===