>The monad laws in the report are an aid to understanding the
>relationships between the monadic functions. I don't think any
>Haskell compiler attempts to optimize method calls based on laws (or
>whatever you want to call them) that would constrain the behavior of
>all instances of a particular
I am having a little trouble following the two discussions on pattern
guards and monads, due to some (probably minor) confusing pieces of
syntax. Would anyone like to clarify these for me? It would help me
to understand the underlying issues. Thanks.
On pattern guards, Simon PJ writes:
>
| > f c | (i,j) <- Just (toRect c) = ...
|
| I'm afraid this example suffers from the same problem as my "simplify"
| example did: It does not perform a test and can thus be replaced by
|
| f c = ...
| where (i,j) = toRect c
True. I can think of two non-contrived ways in which this
> Now, for monads, Phil Wadler writes a law:
> > m >>= \x -> k x ++ h x = m >>= k ++ n >>= k
>
> in which 'h' appears on the lhs but not the rhs, and 'n' on the rhs but
> not the lhs. ... perhaps the equation should read as follows?
> m >>= \x -> k x ++ h x = m >>= k ++ m >>= h
PolyP is a functional language extension that adds polytypic functions to
a subset of Haskell. I have implemented an experimental version of PolyP
(currently version 0.4) that takes a polytypic Haskell program and
translates it to Haskell.
Now I am interested in feedback from users, to further d
Hi,
Well, I do have a preprocessor tool called derive, but it doesn't
currently what I gather Olaf requires, (although this sounds like
another useful application for it, and wouldn't be too hard to add)
What 'derive' does do is allow the derivation of classes which aren't
usually supported by t
Here is another monad definition improving aspect you may think of:
If one defines a monad as
class Monad m where
map :: (a -> b) -> (m a -> m b) -- Functor
return :: a -> m a -- Unit
(>>=) :: m a -> (a -> m b) -> m b -- Kleisli multiplicatio
| On pattern guards, Simon PJ writes:
| > f (x:xs) | x<0 = e1
| > | x>0 = e2
| > | otherwise = e3
|
| then
| > g a | (x:xs) <- h a, x<0 = e1
| > | (x:xs) <- h a, x>0 = e1
| > | otherwise = e3
|
| Am i right in thinking that f [] is bottom, whilst g [] is e3?
