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
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
