Changes between Version 5 and Version 6 of ViewPatternsNew


Ignore:
Timestamp:
Jul 18, 2007 4:44:35 PM (8 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.