Changes between Version 33 and Version 34 of ViewPatterns


Ignore:
Timestamp:
Sep 25, 2007 4:08:15 PM (7 years ago)
Author:
danl
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ViewPatterns

    v33 v34  
    348348'''Efficiency'''  View patterns can do arbitrary computation, perhaps expensive. It's reasonable to expect the compiler to avoid repeated computation when pattern line up in a column, as in `size` at the top of the page.  In pattern-guard form, common sub-expression should achieve the same effect, but it's quite a bit less obvious.  We should be able to give clear rules for when the avoidance of repeat computation is guaranteed. 
    349349 
     350Due to type classes, checking for the "same" view pattern must be type-aware; the same source syntax cannot necessarily be commoned up: 
     351{{{ 
     352class View a b where 
     353    view :: a -> b 
     354 
     355instance View Int Int where 
     356    view x = x 
     357 
     358instance View Int String where 
     359    view _ = "hi" 
     360 
     361-- should not be commoned, even though they're syntactically the same, 
     362-- because they are different uses of the overloaded function 
     363f (view -> 1) = 1 
     364f (view -> "hi") = 2 
     365}}} 
     366 
    350367'''Exhaustiveness/Redundancy.'''  It is hard to check for completeness of pattern matching; and likewise for overlap.  But guards already make both of these hard; and GADTs make completness tricky too. So matters are not much worse than before. 
    351368