Changes between Version 33 and Version 34 of ViewPatterns


Ignore:
Timestamp:
Sep 25, 2007 4:08:15 PM (8 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