Changes between Version 10 and Version 11 of ViewPatternsNew


Ignore:
Timestamp:
Jul 19, 2007 10:21:36 AM (8 years ago)
Author:
danl
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ViewPatternsNew

    v10 v11  
    4242}}} 
    4343that means "apply the expression to whatever we're trying to match against, and then match the result of that application against the pattern".  The expression can be any Haskell expression of function type, and view patterns can be used wherever patterns are currently used. 
     44 
     45The key feature of this proposal is its modesty, rather than its ambition: 
     46  * There is no new form of declaration (e.g. 'view' or 'pattern synonym').   
     47  * The functions used in view patterns are ordinary Haskell functions, and can be called from ordinary Haskell code. 
     48  * No changes are needed to import or export mechanisms. 
     49  * Both static and dynamic semantics are extremely simple. 
     50It is essentially some simple syntactic sugar for patterns. 
     51However, sometimes modest syntactic sugar can have profound consequences. In this case, it's possible that people would start routinely hiding the data representation and exporting view functions instead, which would be an excellent thing. 
    4452 
    4553=== Semantics === 
     
    336344== Compilation == 
    337345 
    338 View patterns can do arbitrary computation, perhaps expensive. 
    339 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. 
     346'''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. 
     347 
     348'''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. 
    340349 
    341350== Features views can have ==