> apfelmus suggested to use '<=' for this purpose, so that,
> wherever monadic generators
> are permitted
>
> pattern <= expr ~~> pattern <- return expr
It was to late when i realized that <= is already used as "smaller than
or equal to" :)
Obviously, the difference between the pattern guard <- and the monadic
<- let easily slips by. I think this has to do with the fact that
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
do
r <- lookup x map
because returning Maybe is a very special case, there are many other
constructors to match on where one wants fall-back semantics. Of course,
every sum type can be projected to Maybe X =~= X + 1 but this involves
boilerplate. In a sense, do-notation is just not appropriate for
MonadPlus Maybe.
It is somewhat unfortunate that while arrows, monads and pattern guards
(= MonadPlus Maybe) could share the same syntax, it is not advisable to
do so because this introduces quite annoying boilerplate. The most
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.
The "partial order of syntax inclusion" should look something like
Arrows
\
\ MonadPlus
\ /
Monad
Even though arrows are more general than monads (less theorems hold),
they require more syntax. On the other hand, MonadPlus provides more
than a monad, so it needs a new syntax, too.
Remember that these are not the only computation abstractions. Syntactic
sugar for pseudo-let-declarations (akin to MonadFix but order
independent, can be embedded using observable sharing) is advisable,
too. Only applicative functors behave very nicely and fit into current
Haskell syntax (maybe that's the reason why they have been discovered
only lately? :). In a sense, even ordinary Haskell (= pure functions) is
only "syntactic sugar". Some "higher order syntactic sugar" melting
machine bringing all these candies together would be very cool.
Regards,
apfelmus
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
