name:
introduce lambda-match (explicit match failure and fall-through)
Dear All,
may I be so optimistic as to interpret the absolute lack of counter
arguments over the last week as indication that this proposal is
acceptable in general? Thanks to those few who have expressed
support so far, usually in the form "I've wanted something like
this for years"! (*)
I have braved the evil trac-wiki formatter again, to convert the email
proposal into a slightly updated ticket, with attached patch for GHC,
support libraries and usage examples:
introduce lambda-match (explicit match failure and fall-through)
http://hackage.haskell.org/trac/haskell-prime/ticket/114
most notable updates are in the support library (now being a bit
more helpful in preserving error messages and defining fall_through
cases; also supports joining of nested matches now), with a few
added examples demonstrating the changes.
It is a good sign that the syntax patch itself has not changed so far,
and the support library now supports most of what I had in mind
for it (took me a while to figure out how to do "nest" ;-). But it
would be very helpful if more eyes looked over the code, to see
if the functionality is roughly right (not to mention the implementation).
And, of course, syntax patches for other Haskell implementations
would be great (at least verify whether your favourite implementation
can handle the support library, please - so far verified for GHC and
Hugs)!
Thank you,
Claus
ps. a quick recap for those who don't read webpages: a
lambda-match
| <patterns> | <guards> -> <expr>
is syntactic sugar for
\ <parameters> -> case <parameters> of
{ <patterns> | <guards> -> Match $ return <expr>
; _ -> Match $ fail "lambda-match failure" }
which allows us to program explicitly with match failure
(represented as Monad.fail/MonadPlus.mzero) and match
fall-through (using MonadPlus.mplus), lifting MonadPlus
operations over function parameters for ease of use.
this enables us to write previously practically impossible
things (the example file gives some indication of just how
unreadable and hence unusable these would be without
syntactic sugar), such as a user-defined case-variant
(included in the library):
caseOf True $ ( |True-> False ) +++ ( |False-> True )
-->
False
or monadic match-failure without using do-notation:
return True >>= (ok $ |False-> return "hi") :: Maybe String
-->
Nothing
lambda-matches may be nested, but unlike PMC, that will
usually result in nested match monads, unless we use the new
"nest" to join the nested monads:
myAnd = splice (nest (|True-> (|True->True)
+++ (|False->False))
+++ nest (|False-> fall_through False) )
we can now also abstract over groups of match alternatives:
grp :: MonadPlus m => String -> [(String, String)] -> Match m String
grp = (| x locals | Just y <- lookup x locals -> y)
+++ (| "X" locals -> "42")
+++ matchError "var not found"
and extend them later, or just use them to build different functions:
-- select only the first match
varVal :: String -> [(String, String)] -> String
varVal = spliceE grp
-- a variation, delivering all successful matches
varVals :: String -> [(String, String)] -> [] String
varVals = allMatches grp
leading to uses like these:
*Main> varVal "X" [("X","hi")]
"hi"
*Main> varVal "Z" [("X","hi")]
"*** Exception: var not found
*Main> varVals "X" [("X","hi")]
["hi","42"]
*Main> varVals "Z" [("X","hi")]
[]
and so on, and so on.. see the proposal attachments for more
inspirations !-)
(*) it might be useful for the Haskell' committee to clarify the
process for acceptance of proposals, similar to what the
Haskell library community has done recently:
http://haskell.org/haskellwiki/Library_submissions
(where the intent of the discussion period is to focus the
process, and to ensure progress, ie lack of objections to
a clearly implementable/implemented proposal is seen as
implicit agreement)
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
