Hi Simon, Those additional reasons given are much more compelling, and should definately go on the wiki. I think the essential point is that it makes reasoning about the code simpler - regardless of the effect on implementation.
My main remaining reservation is that: (x) /= x [EMAIL PROTECTED] /= x It really worries me that (caf) = foo Can be in an entirely different complexity class from caf = foo. It seems like the kind of "refactoring" that beginners will be immediately drawn to, and even experienced programmers will get tripped up on. Anyone doing (caf) is virtually going to be required to add a comment just above stating that the brackets are essential. Does it still work if you relax the definitions so that [EMAIL PROTECTED] is a pattern binding only if y is a pattern binding, and (x) is a pattern binding only if x is a pattern binding? Thanks Neil On 4/25/08, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote: > | The report doesn't actually mention this translation although it is > | widely used to implement pattern bindings, and in some compilers (not > | GHC) the translation is done before type checking. > | > | What's interesting to me is that perhaps this gives us a way to > | understand what the static semantics of pattern bindings should be, > | absent MPB. e.g. > > > Yes, that's a fine point. If this became the formal definition of the > *static* semantics of pattern bindings, that would be a significant > improvement, because it'd give us a precise way to answer the various > questions I asked. (We might or might not like the answers, but at least we > could answer them.) > > > Simon > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime