5 | | Haskell 98 provides *two different translations* of lambda |
6 | | abstractions involving pattern matching, only one of which is |
7 | | directly accessible (Section 3.3 - the other is embedded in the |
8 | | translation of do-notation, see "ok" in Section 3.14). |
| 5 | Haskell 98 provides *two different translations* of lambda |
| 6 | abstractions involving pattern matching, only one of which is |
| 7 | directly accessible (Section 3.3 - the other is embedded in the |
| 8 | translation of do-notation, see "ok" in Section 3.14). |
10 | | providing explicit source notation for the second translation, |
11 | | substantially simplifies programmability of pattern-match |
12 | | fall-through by reification of pattern-match failure, two |
13 | | central language features that are so far only available |
14 | | through the built-in, non-composable case construct. |
| 10 | Providing explicit source notation for the second translation, |
| 11 | substantially simplifies programmability of pattern-match |
| 12 | fall-through by reification of pattern-match failure, two |
| 13 | central language features that are so far only available |
| 14 | through the built-in, non-composable case construct. |
23 | | with xi fresh identifiers, and pattern-match failure resulting in |
24 | | _|_. the latter is unfortunate, and results in partial functions the |
25 | | coverage of which cannot be combined, but it is forced by |
26 | | translation into conventional lambda calculus. |
| 23 | with xi fresh identifiers, and pattern-match failure resulting in |
| 24 | _|_. the latter is unfortunate, and results in partial functions the |
| 25 | coverage of which cannot be combined, but it is forced by |
| 26 | translation into conventional lambda calculus. |
28 | | since computational lambda calculus (\-M) has become a central part |
29 | | of Haskell programming practice, there shall be an alternative form |
30 | | of lambda abstraction, dubbed here '''lambda-match''', with associated |
31 | | translation into \-M: |
| 28 | since computational lambda calculus (\-M) has become a central part |
| 29 | of Haskell programming practice, there shall be an alternative form |
| 30 | of lambda abstraction, dubbed here '''lambda-match''', with associated |
| 31 | translation into \-M: |
37 | | ''[note1: this is the translation in principle - in practice, to enable composition of lambda-matches without further language extensions, a slight modification is needed, wrapping the right-hand sides of the case in a Match constructor, see library, examples, and patch]'' |
| 37 | ''[note1: this is the translation in principle - in practice, to enable composition of lambda-matches without further language extensions, a slight modification is needed, wrapping the right-hand sides of the case in a Match constructor, see library, examples, and patch]'' |
39 | | a library for composing these lambda-matches provides for |
40 | | composition of alternative lambda-matches ( {{{(+++)}}} ), match failure |
41 | | ({{{nomatch}}}, {{{matchError <message>}}}) and embedding of the explicit |
42 | | match monad into pure expressions ({{{splice}}}, where |
43 | | {{{ \p1..pn->e = splice |p1..pn->e }}}, also {{{spliceE}}} -preserving |
44 | | error messages by using {{{(Either String)}}} as the match monad, and |
45 | | {{{allMatches}}}, using the {{{[]}}} monad to deliver all successful matches). |
46 | | other lambda-match related auxiliaries include {{{caseOf}}} as a |
47 | | user-defined version of {{{case _ of _}}}, argument supply to matches |
48 | | ( {{{(>|)}}} ), and joining of nested matches (so that, for instance |
| 39 | a library for composing these lambda-matches provides for |
| 40 | composition of alternative lambda-matches ( {{{(+++)}}} ), match failure |
| 41 | ({{{nomatch}}}, {{{matchError <message>}}}) and embedding of the explicit |
| 42 | match monad into pure expressions ({{{splice}}}, where |
| 43 | {{{ \p1..pn->e = splice |p1..pn->e }}}, also {{{spliceE}}} -preserving |
| 44 | error messages by using {{{(Either String)}}} as the match monad, and |
| 45 | {{{allMatches}}}, using the {{{[]}}} monad to deliver all successful matches). |
| 46 | other lambda-match related auxiliaries include {{{caseOf}}} as a |
| 47 | user-defined version of {{{case _ of _}}}, argument supply to matches |
| 48 | ( {{{(>|)}}} ), and joining of nested matches (so that, for instance |
68 | | minimal - limited to an extension in parser/desugarer, employing |
69 | | previously inaccessible syntax for lambda-match, and a slight |
70 | | variation of the existing lambda translation; also adds a small |
71 | | library to support composition of matches. |
| 68 | minimal - limited to an extension in parser/desugarer, employing |
| 69 | previously inaccessible syntax for lambda-match, and a slight |
| 70 | variation of the existing lambda translation; also adds a small |
| 71 | library to support composition of matches. |
76 | | as has been pointed out in the thread on replacing and improving |
77 | | pattern guards, Haskell's pattern matching support, even before |
78 | | pattern guards, is monolithic (built-in case is the only way to handle |
79 | | multiple alternative matches) rather than compositional (lambdas |
80 | | represent individual alternatives, but cannot be composed on |
81 | | match fall-through). this implies increased complexity of the language |
82 | | definition and limited expressiveness of its features, when compared |
83 | | with alternative models (eg, adapting Wolfram's pattern match |
84 | | calculus for Haskell). see, eg.: |
| 76 | as has been pointed out in the thread on replacing and improving |
| 77 | pattern guards, Haskell's pattern matching support, even before |
| 78 | pattern guards, is monolithic (built-in case is the only way to handle |
| 79 | multiple alternative matches) rather than compositional (lambdas |
| 80 | represent individual alternatives, but cannot be composed on |
| 81 | match fall-through). this implies increased complexity of the language |
| 82 | definition and limited expressiveness of its features, when compared |
| 83 | with alternative models (eg, adapting Wolfram's pattern match |
| 84 | calculus for Haskell). see, eg.: |
86 | | http://www.haskell.org/pipermail/haskell-prime/2006-October/001713.html |
87 | | http://www.haskell.org/pipermail/haskell-prime/2006-October/001720.html |
88 | | http://www.haskell.org/pipermail/haskell-prime/2006-October/001723.html |
89 | | http://www.haskell.org/pipermail/haskell-prime/2006-October/001724.html |
| 86 | http://www.haskell.org/pipermail/haskell-prime/2006-October/001713.html |
| 87 | http://www.haskell.org/pipermail/haskell-prime/2006-October/001720.html |
| 88 | http://www.haskell.org/pipermail/haskell-prime/2006-October/001723.html |
| 89 | http://www.haskell.org/pipermail/haskell-prime/2006-October/001724.html |
100 | | in principle, replacing Haskell's current pattern matching support |
101 | | with a simpler, more compositional model, and defining the current |
102 | | constructs on top of that new core is the way forward, IMHO. in |
103 | | practice, however, I suspect that the committee is less than tempted |
104 | | to introduce such a substantial simplification for Haskell'. |
| 100 | in principle, replacing Haskell's current pattern matching support |
| 101 | with a simpler, more compositional model, and defining the current |
| 102 | constructs on top of that new core is the way forward, IMHO. in |
| 103 | practice, however, I suspect that the committee is less than tempted |
| 104 | to introduce such a substantial simplification for Haskell'. |
106 | | the present proposal is an attempt at a compromise, suggesting a |
107 | | minimal language change to introduce compositional pattern-match |
108 | | failure and fall-through. with lambda-match, it implements only a |
109 | | single language extension (as syntactic sugar), delegating the rest |
110 | | of the functionality to a library. without the sugar, the result of the |
111 | | by-hand translation becomes so hard to read as to be near |
112 | | unusable, while the chosen form of sugaring allows to provide |
113 | | most of the language features discussed in the earlier threads to |
114 | | be provided as a library. this does seem to be a useable balance. |
| 106 | the present proposal is an attempt at a compromise, suggesting a |
| 107 | minimal language change to introduce compositional pattern-match |
| 108 | failure and fall-through. with lambda-match, it implements only a |
| 109 | single language extension (as syntactic sugar), delegating the rest |
| 110 | of the functionality to a library. without the sugar, the result of the |
| 111 | by-hand translation becomes so hard to read as to be near |
| 112 | unusable, while the chosen form of sugaring allows to provide |
| 113 | most of the language features discussed in the earlier threads to |
| 114 | be provided as a library. this does seem to be a useable balance. |
116 | | building constructs of the simpler pattern-match model on top of |
117 | | the more complex one is somewhat irksome from a language design |
118 | | perspective, but does at least gain the expressiveness of the simpler |
119 | | model. if programmers make substantial use of this new functionality |
120 | | in Haskell' (as I strongly suspect they will - I have been doing similar |
121 | | translations by hand for some time now), it will be up to Haskell'' to |
122 | | turn the table, and to define the current complex model on top of a |
123 | | compositional one. |
| 116 | building constructs of the simpler pattern-match model on top of |
| 117 | the more complex one is somewhat irksome from a language design |
| 118 | perspective, but does at least gain the expressiveness of the simpler |
| 119 | model. if programmers make substantial use of this new functionality |
| 120 | in Haskell' (as I strongly suspect they will - I have been doing similar |
| 121 | translations by hand for some time now), it will be up to Haskell'' to |
| 122 | turn the table, and to define the current complex model on top of a |
| 123 | compositional one. |
131 | | - the second translation avoids any direct reference to case, employing do-notation instead; this requires slightly more effort, eg. in translating pattern guards into the match monad, but is eminently suitable for adding the new features to implementations that do not support pattern guards yet, or that simply want to reduce the number of built-in constructs. ''[patchers for Hugs, etc., might want to follow this route?]'' |
| 131 | * the second translation avoids any direct reference to case, employing do-notation instead; this requires slightly more effort, eg. in translating pattern guards into the match monad, but is eminently suitable for adding the new features to implementations that do not support pattern guards yet, or that simply want to reduce the number of built-in constructs. ''[patchers for Hugs, etc., might want to follow this route |