Heribert Schuetz:
> I wanted to point out
> that no use of patterns is really "essential" (see also the equivalences
> below), or at least that it is a bit arbitrary what one considers
> essential.
Let me rephrase then; it wasn't a convincing example, because the
non-pattern-guarding version (5a vs. 5) was actually simpler and
cleaner, but in basically the same style. This does not seem to me to
be the case for arbrary uses of pattern guards (so I don't see it as an
argument against them), whereas it remains to be shown that the same is
true for nested pattern guards, and/or Maybe-style pattern guards.
> But where can I get Simon's examples that you mentioned?
I referred to the ones in Simon's first message (Lists and Rects, I
think). Obviously they can be recast to use the Maybe-style -- perhaps
it comes down to whether the Maybe case occurs "naturally" considerably
more often than any others. If it does, then I'd be prepared to put
up with having to write the occassional spurious-looking "Just".
> (We have a similar restriction to Bool in guards now, simply because
> it makes sense.)
That's a very loose comparison; nothing in the syntax for guards
hints that they _should_ have a more general interpretation, whereas
"<-" does at least suggest monads (or a different particular monad,
according to taste).
> - In the Id case it is a mutated version of the Monad, as you said.
> Haskell syntax does not support the identity monad, and also the
> semantics is not really the one of an identity monad, because the
> latter cannot fail (i.e., is not a MonadZero).
It may be that because the type can represent "failure", it's more
intuitive to use here, but I find this appeal to its "monadicness"
continues to be unconvincing. If it's really true that Maybe is
the thing to use because it's a Monad, MonadZero, and MonadPlus,
why isn't it equally true of some other M satisfying the same
type constraint?
[Equation between maybe-p-guards and maybe monad]
A more concise translation would be, for each clause of a function f:
f as | pgs = e
==>
f as | isJust m = fromJust m
where m = [ e | pgs ]
(Or for those who haven't been Gotcha'd by the 1.4 Maybe Library yet:
f as | e = t where (t,e) = theExists [ e | pgs ]
)
The non-Maybe pattern guards can be translated in the same way, with
the additional step of doing, for each generator in pgs:
p <- e
==>
p <- Just e
Granted the translation for the Maybe style is somewhat more direct,
but I don't find this particularly compelling.
> Do similar equivalences hold for the identity approach? Does the
> identity approach require/provide an extension of the Haskell Kernel?
Note that Chris Dornan already gave a translation of pattern-guards into
"core" Haskell.
> f xs | False = xs
>
> currently means that "f [1, 2, 3]" is undefined whereas with the
> generalized monadic approach "f [1, 2, 3]" would be the empty list.
> (Did I get this right?)
Obviously, boolean guards need to be treated distinctly; as they're
not a monadic type, I don't think the above translation is even possible,
much less appropriate. If one wanted to unify the two, one could do
the following:
b ==> True <- b
or
b ==> True <- Just b
according to preferred style of p-guard (non-Maybe or Maybe).
Guillermo Calderon has yet another non-clunky clunky:
> >clunky env var1 var2 =
> > fromMaybe (var1 + var2)
> > [val1 + val2 | val1 <- lookup var1 env
> > , val2 <- lookup var2 env]
> Does somebody know another illustrative example which cannot be
> solved with monadic operators?
It's a question of clarity, not expressivity. For a larger example,
I think the above style would be less pleasant-looking, as it's
based on translating several independant equations into one single
RHS; the "one" could get arbitrarily complexified.
Cheers,
Alex.
