Changes between Version 3 and Version 4 of ViewPatterns


Ignore:
Timestamp:
Jan 22, 2007 2:57:16 PM (8 years ago)
Author:
simonpj@…
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ViewPatterns

    v3 v4  
    105105is used to match the second argument of `g`. 
    106106 
    107 === A possible extension === 
     107=== Possible extension 1: multi-argument view patterns === 
    108108 
    109109It would be quite useful to allow more than one sub-pattern in a view 
     
    160160following the `->`. 
    161161 
     162== Possible extension 2: the implicit `Maybe`  == 
     163 
     164Thus far, the view function is required to return a `Maybe` type, with `Nothing` to indicate match 
     165failure.  An alternative, presented in the Erwig paper on transformational patterns (see Related work below),  
     166this implicit matching is not performed; instead, the sub-pattern is matched against 
     167whatever the view function returns.  So you'd have to write: 
     168{{{ 
     169f (snoc -> Just2 xs x) = ... 
     170}}} 
     171(Note the tiresome `Just2`.) 
     172The benefit of not having the implicit matching is that you can write functions that are, perhaps, 
     173more view-like.  Example: 
     174{{{ 
     175data Product = ....some big data type... 
     176 
     177data Size = Small | Medium | Big        -- View type 
     178prodSize :: Product -> Size 
     179prodSize = .... 
     180 
     181f :: Product -> ... 
     182f (prodSize -> Small)  = ... 
     183f (prodSize -> Medium) = ... 
     184f (prodSize -> Big)    = ... 
     185}}} 
     186With the built-in `Maybe` proposal, you'd instead write something like this: 
     187{{{ 
     188smallProd, medProd, bigProd :: Product -> Bool 
     189smallProd p = ... 
     190medProd   p = ... 
     191bigProd   p = ... 
     192 
     193f :: Product -> ... 
     194f (smallProd ->) = ... 
     195f (medProd   ->) = ... 
     196f (bigProd   ->) = ... 
     197}}} 
     198This is not obviously worse, except that the first version is more 
     199obviously exhaustive.  Incidentally, both should generate the same 
     200code. 
     201 
     202I can think of three alternatives: 
     203 * The `Maybe` stuff is built-in. This is the main proposal, because I think it is often exactly what you want. 
     204 * No built-in `Maybe` stuff.  Arguably this is more consistent with pattern-guards. 
     205 * Both are available, with different syntax.  For example  
     206    * ''(expr `->` pat)'' for the built-in `Maybe` story 
     207    * ''(expr `=>` pat)'' with no bulit-in `Maybe` 
     208  
    162209== Efficiency == 
    163210 
     
    368415There are two main differences (apart from syntax). 
    369416First, transformational patterns didn't have the value input feature, althought it'd be easy  
    370 to add (indeed that's what we've done). Second, : in the current 
    371 proposal the view function is expected to return a `Maybe` type, with `Nothing` to indicate match 
    372 failure.  In the transformational pattern paper, this implicit matching is not performed. So, 
    373 using the new syntax, you'd have to write 
    374 {{{ 
    375 f (snoc -> Just2 xs x) = ... 
    376 }}} 
    377 The benefit of not having the implicit matching is that you can write functions that are, perhaps, 
    378 more view-like.  Example: 
    379 {{{ 
    380 data Product = ....some big data type... 
    381  
    382 data Size = Small | Medium | Big        -- View type 
    383 prodSize :: Product -> Size 
    384 prodSize = .... 
    385  
    386 f :: Product -> ... 
    387 f (prodSize -> Small)  = ... 
    388 f (prodSize -> Medium) = ... 
    389 f (prodSize -> Big)    = ... 
    390 }}} 
    391 With the current proposal, you'd instead write something like this: 
    392 {{{ 
    393 smallProd, medProd, bigProd :: Product -> Bool 
    394 smallProd p = ... 
    395 medProd   p = ... 
    396 bigProd   p = ... 
    397  
    398 f :: Product -> ... 
    399 f (smallProd ->) = ... 
    400 f (medProd   ->) = ... 
    401 f (bigProd   ->) = ... 
    402 }}} 
    403 This is not obviously worse, except that the first version is more 
    404 obviously exhaustive.  Incidentally, both should generate the same 
    405 code. 
    406  
    407 While I think the implicit Maybe-stripping is a real win, it's an open 
    408 design choice.  Perhaps a different arrow could suppress the 
    409 stripping? 
     417to add (indeed that's what we've done). Second, transformational patterns as described by 
     418Erwig do no stripping of the `Maybe` (see "Possible extension 2" above). 
     419 
    410420 
    411421=== Pattern synonyms  === 
     
    464474anything about the patterns themselves, which in turn is all this 
    465475proposal deals with.  Hence orthgonal. 
    466