A couple of minor counter-quibbles:-
Pablo E. Martinez Lopez suggests:
> You can define your own "sequential if" a la Hoare:
>
> data GuardedExp a = Bool :? a
>
> seqif :: [GuardedExp a] -> a
> seqif [True:?a] = a
> seqif ((b:?a):x:xs) = if b then a else seqif (x:xs)
>
> and then you can write:
>
> seqif [
> test1 :? part1,
> test2 :? part2,
> test3 :? part3
> ]
This captures Chris' suggested conditional insofar as it corresponds to
existing Haskell if/boolean case functionality. But this doesn't, and
can't be made to, do any sort of pattern-binding, so it's not possible
to express pattern guards like this. (Or reduce them to such in the
same style of translation as Chris gave.)
Brian Boutel comments on Simon's:
> > CONCLUSION: "let" should be allowed, but should introduce multiple,
> > mutually-recursive bindings. If any are pattern bindings then they
> > are matched lazily, and failure to match is a program error. Exactly
> > as for ordinary let/where bindings, and let bindings in list
> > comprehensions.
> Agreed.
As I understand it, this would rule out using "let p = e" as a
synonym/alternative for "p <- e"; it wouldn't give the same (or any)
"guarding" effect. If some variant not using "<-" were to do the
same job, some other syntax than "let =" really ought to be used.
Perhaps there's a case for some general "strict let" construct, though
I can't say I've ever felt the need for it myself.
Cheers,
Alex.
