Changes between Version 5 and Version 6 of ViewPatternsNew


Ignore:
Timestamp:
Jul 18, 2007 4:44:35 PM (7 years ago)
Author:
danl
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ViewPatternsNew

    v5 v6  
    332332 
    333333Of course, a programmer can always use all three type classes explicitly; it's just a question of which one should be the default.  We plan to try them out before deciding. 
     334 
     335== Features views can have == 
     336 
     337To distinguish between the different proposals, we identify some features of views. 
     338 
     339=== Value input feature === 
     340 
     341Our proposal has the ''value input'': the view function can be passed parameters; in a function definition, those parameters can mention previous arguments.  For example, this permits a view function itself to be passed as an argument, so patterns, in a sense, become first class. 
     342 
     343=== Implicit `Maybe` feature === 
     344 
     345Our proposal has the ''implicit `Maybe`'' feature: the syntax ''expr'' `=>` ''pat'' permits the programmer to elide the `Just`, for example when using partial views.   
     346 
     347=== Transparent ordinary Patterns === 
     348 
     349Our proposal does not have the ''transparent ordinary patterns'' feature: view patterns are written differently than ordinary patterns. 
     350There are pros and cons both ways: 
     351The advantage of having transparent ordinary patterns is that you can replace a concrete datatype with an abstract type and a view without changing client code.  A disadvantage is that view patterns can do arbitrary computation, perhaps expensive, so it's good to have a syntactic marker that some computation beyond ordinary pattern matching may be going on.  Another disadvantage is that transparent ordinary patterns require a larger language extension than just a new form of pattern, so that certain names may be declared to be view constructors for a type.  We consider our proposal's implicit view syntax `(-> e)` to be a nice compromise between the two alternatives.   
     352 
     353=== Nesting === 
     354 
     355Our proposal has the ''nesting'' feature: view patterns nest inside other patterns, and other patterns nest inside them. Nexting is perhaps the biggest practical difference between view patterns and pattern guards. 
     356 
     357=== Integration with type classes === 
     358 
     359Our proposal ''integrates with type classes'': a single "view" can decompose multiple different data types.