Changes between Version 3 and Version 4 of ViewPatterns


Ignore:
Timestamp:
Jan 22, 2007 2:57:16 PM (9 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