ooohh.. when I saw the subject, I fully expected a worked out proposal for extensible syntax in Haskell, just in time for Christmas. well, maybe next year!-)
It was to late when i realized that <= is already used as "smaller than or equal to" :)
oops. okay, lets change that. what about this: pattern =< expr ~~> pattern <- return expr a cleaner variant would be a let!, perhaps, but that would probably be too noisy for pattern guards? (also, we don't want to steal nice infix ops like <==)
do-notation is not the natural style for MonadPlus Maybe, the natural style is more like the current syntax of pattern guards. I mean that one rarely hides a Just constructor like in
oh? getting rid of nested (case x of {Just this ->..; Nothing -> that}) is a very good argument in favour of do-notation for Maybe, and I find that very natural (for some definition of nature;-). granted, once one has taken that step, one is close to writing in monadic style anyway, so it is no longer specific which constructors are hidden. but I don't see a specific problem with Maybe there, and I haven't seen convincing sugar for MonadPlus yet.
general syntax is too much for the special case. But there is something more canonical than completely disjoint syntax: in a sense, Claus' suggestions are about making the syntax for the special case a *subset* of the syntax for the more general one.
indeed. thanks for pointing that out. I first went the other direction, but as you say, generalizing pattern guards introduces too much syntax in an awkward place. so my current suggestion follows the subset idea.
Some "higher order syntactic sugar" melting machine bringing all these candies together would be very cool.
hooray for extensional syntax!-) syntax pre-transformation that would allow me to extend a Haskell parser in library code is something I'd really like to see for Haskell, possibly combined with error message post-transformation. together, they'd smooth over the main objections against embedded DSLs, or allow testing small extensions of Haskell. I have been wondering in the past why I do not use Template Haskell more, given that I'm a great fan of meta-programming and reflection, and I think the answer is that it sits in an unfortunate way between two chairs: it cannot quite be used for syntax extensions because it insists on Haskell syntax/scopes/types, and it cannot quite be used as a frontend because there's some typing coming after it. persistent users have found wonderful things to do with it nevertheless, even analysis/ frontend stuff, but its main use seems to be program-dependent program generation, within the limits of Haskell syntax. in fact, I have a pragmatic need for even more, namely type system extensions as well: somewhere on my disk, I have a type-directed monadification prototype, based on a type system that infers not just a type, but a type coercion; works well, at least for simple monomorphic code, but what do I do with it? being type-directed, it uses a completely different foundation than the rest of HaRe refactorings, and to fully realize it for Haskell, I'd have to implement and -here comes the killer- maintain a complete Haskell type system, just because I need a few modifications/extensions. it is just not practical to do so, let alone once for every type-directed algorithm. Claus