"Higher order syntactic sugar"

[Claus Reinke]

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