Changes between Version 5 and Version 6 of ViewPatterns


Ignore:
Timestamp:
Jan 23, 2007 9:04:58 AM (9 years ago)
Author:
simonpj@…
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ViewPatterns

    v5 v6  
    304304}}}
    305305
     306== Concrete syntax ==
     307
     308Here are some other possible syntax choices I've considered:
     309{{{
     310  f ($snoc x xs) = ...          -- Use prefix "$"
     311  g ($(bits 3) x bs) = ...      -- Extra parens for the value input feature
     312
     313  f (%snoc x xs) = ...          -- Or use prefix "%" instead
     314
     315  f (.snoc x xs) = ...          -- Or use prefix "." instead
     316
     317  f (snoc | x xs) = ..          -- Use "|" instead of "->"
     318  g (bits 3 | b bs) = ...
     319}}}
     320
     321I also thought about infix view patterns, where the view function
     322appears between its (pattern) arguments, but I could not think of a
     323nice syntax for it, so it is not provided by this proposal.
     324
    306325== Remarks ==
    307326
    308 '''Note 0'''.  A key feature of this proposal is its modesty; it is essentially simply some syntactic sugar for patterns:
     327The key feature of this proposal is its modesty, rather than its ambition:
    309328  * There is no new form of declaration (e.g. 'view' or 'pattern synonym'). 
    310329  * The functions used in view patterns are ordinary Haskell functions, and can be called from ordinary Haskell code.  They are not special view functions.
    311330  * Since the view functions are ordinary Haskell functions, no changes are needed to import or export mechanisms.
    312331  * Both static and dynamic semantics are extremely simple.
     332It is essentially some simple syntactic sugar for patterns.
    313333However, sometimes modest syntactic sugar can have profound consequences.
    314334In this case, it's possible that people would start routinely hiding
     
    316336be an excellent thing.
    317337
    318 '''Note 1'''.  All this could be done with pattern guards.  For example `parsePacket` could be written
     338All this could be done with pattern guards.  For example `parsePacket` could be written
    319339{{{
    320340  parsePacket bs | Just (n, bs')    <- bits 3 bs
     
    322342                 = ...
    323343}}}
    324 But it's a bit more clumsy.  I'm hoping that support for view patterns might encourage people to export
    325 view functions (ones with `Maybe` return types, and encouage their use in patten matching).  That is,
     344Indeed, one might ask whether the extra syntax for view patterns is worth
     345it when they are so close to pattern guards. 
     346That's a good question.  I'm hoping that support for view patterns
     347might encourage people to export view functions (ones with `Maybe`
     348return types, and encouage their use in patten matching).  That is,
    326349just lower the barrier for abstraction a bit.
    327350
    328 '''Note 2'''.  It is hard to check for completeness of pattern matching; and likewise for
     351'''Completeness'''.  It is hard to check for completeness of pattern matching; and likewise for
    329352overlap.  But guards already make both of these hard; and GADTs make completness hard too.
    330353So matters are not much worse than before.
    331354
    332 == Concrete syntax ==
    333 
    334 Here are some other possible syntax choices I've considered:
    335 {{{
    336   f ($snoc x xs) = ...          -- Use prefix "$"
    337   g ($(bits 3) x bs) = ...      -- Extra parens for the value input feature
    338 
    339   f (%snoc x xs) = ...          -- Or use prefix "%" instead
    340 
    341   f (.snoc x xs) = ...          -- Or use prefix "." instead
    342 
    343   f (snoc | x xs) = ..          -- Use "|" instead of "->"
    344   g (bits 3 | b bs) = ...
    345 }}}
    346 
    347 I also thought about infix view patterns, where the view function
    348 appears between its (pattern) arguments, but I could not think of a
    349 nice syntax for it, so it is not provided by this proposal.
    350355
    351356-------------------------
     
    465470Erwig do no stripping of the `Maybe` (see "Possible extension 2" above).
    466471
     472=== [http://lambda-the-ultimate.org/node/1960 Emir, Odersky, Williams: Matching objects with patterns]
     473
     474Scala is an OO language with lots of functional features.  It has algebraic data types and
     475pattern matching.  It also has a form of view called '''extractors''', which are
     476pretty similar to view patterns, albeit in OO clothing.  Notably, by packaging a constructor
     477and an extractor in a class, they can use the same class name in both expressions and terms,
     478implicitly meaning "use the constructor in expressions, and use the extractor in patterns".
     479
     480The paper does a comparative evaluation of various OO paradigms for matching, and
     481concludes that case expressions and extractors work pretty well.
    467482
    468483=== Pattern synonyms  ===