Oh, I forgot to say, concerning the Alternative Syntax (strict where's)
Simon mentions; I think this is not supportable, particularly for the
program-breaking reason SPJ mentions. (And especially because lots of
the borken programs would be mine, and I shudder at the thought of
adding ~'s all over the place.) It would be preferable to have
something like:
f pats = e1
such that gdpats
| e2
otherwise
where defs
But this still suffers from most of the other flaws mentioned. With
M*r*nd*/Orwell-style guards this would seem more reasonable, but it
doesn't really fit with Haskell's LHSomania.
Tommy Thorn:
> Something like
>
> cond
> x == y -> same x
> x == y*2 -> haly x
> .....
> otherwise -> default x
>
> would be much easier on my stomach.
I think I agree, though I think it still looks uglier than good old
if-the-else, its acknowleged flaws notwithstanding. I don't think
there's a sufficient case for removing i-t-e entirely, so it's
arguable that having both would be yet more language clutter.
Chris' translation of pattern guards into these beasties is quite
neat, but one can always (as he mentions) get the same effect by
normalising them to a $case () of { _ | g -> e1 ; _ -> e2 }$ form.
Simon Marlow:
> Reversing this idea, we have another syntax for Simon's generalised
> guards:
>
> f x y | x@(Just 3) = e
>
> This to me is nicer than re-using <- in a different setting. Ok, it
> means more than a one-symbol change to the grammar. Comments?
This would required allowing the "x" to be an _expression_, though, to
capture guarding; that seems a rather more drastic re-use, and even
more confusing on the eye.
Libor Skarvada:
> Actually f _is_ the map function (map^{Id} in identity monad ;-)
> (I understand Simon Peyton Jones' proposed syntax as one restricting
> the meaning of <- to identity monad just like the list comprehension
> [ g x | x <- l ] is restricting <-'s meaning to list monad.)
Except that in 1.4, [ g x | x <- l ] _isn't_ restricted to lists,
whereas the case for pattern guards expressing an arbitrary monad
seems highly conjectural. (Though it doesn't have the same type as
map g, just to be confusing, as that's still given a Functoresque
type, something I was momentarily bemused by, though I did convince
myself it was Categorically Correct.)
Slainte,
Alex.
