Since a tree is a kind of container, yes, it should be a monad. [I'm still
not really sure whether it's useful.]
I have a use for the tree monad -- well, I have a use for the monadic
`join' operation (but I don't use any of the monadic operations other
than `return').
My program is making a
I have another implementation of FreeModule which specializes S to the
natural numbers: but the set of functions f :: \mathbb{N} - R are
isomorphic with f :: [R] (provided we only permit infinite lists), in
the same way that Dave Menendez describes how f :: Bool - a is
isomorphic to f ::
On Sat, May 17, 2008 at 1:24 AM, Kim-Ee Yeoh [EMAIL PROTECTED] wrote:
Dan Piponi-2 wrote:
In fact, you can use the Reader monad as a fixed size container monad.
Interesting that you say that. Reader seems to me more as an anti-container
monad.
You just have to think of the environment as
Andrew Coppin wrote:
Janis Voigtlaender wrote:
http://wwwtcs.inf.tu-dresden.de/~voigt/mpc08.pdf
It is well-known that trees with substitution form a monad.
...OK, I just learned something new. Hanging around Haskell Cafe can
be so illuminating! :-)
Now, if only I could actually comprehend
On Fri, May 16, 2008 at 12:03 PM, Andrew Coppin
[EMAIL PROTECTED] wrote:
Since a tree is a kind of container, yes, it should be a monad. [I'm still
not really sure whether it's useful.]
Not so much containers in general, but 'flattenable' containers. You
can flatten a list of lists to a list
Dan Piponi-2 wrote:
In fact, you can use the Reader monad as a fixed size container monad.
Interesting that you say that. Reader seems to me more as an anti-container
monad.
--
View this message in context:
On Wed, May 14, 2008 at 1:38 AM, Janis Voigtlaender
[EMAIL PROTECTED] wrote:
Graham Fawcett wrote:
Yes, but that's still a 'quick' short-circuiting. In your example, if
'n' is Nothing, then the 'f = g = h' thunks will not be forced
(thanks to lazy evaluation), regardless of associativity.
Janis Voigtlaender wrote:
http://wwwtcs.inf.tu-dresden.de/~voigt/mpc08.pdf
It is well-known that trees with substitution form a monad.
...OK, I just learned something new. Hanging around Haskell Cafe can be
so illuminating! :-)
Now, if only I could actually comprehend the rest of the
On Wed, May 14, 2008 at 12:03 PM, Andrew Coppin
[EMAIL PROTECTED] wrote:
It is well-known that trees with substitution form a monad.
Now that's funny. Compare with the first line of this paper:
http://citeseer.ist.psu.edu/510658.html
Anyway, I worked through an elementary example of this with
On Wed, 2008-05-14 at 12:42 -0700, Dan Piponi wrote:
On Wed, May 14, 2008 at 12:03 PM, Andrew Coppin
[EMAIL PROTECTED] wrote:
It is well-known that trees with substitution form a monad.
Now that's funny. Compare with the first line of this paper:
http://citeseer.ist.psu.edu/510658.html
Yes, I had always desired that the operator = should have been right
associative for this short cut even when written without the 'do' notation.
On Tue, May 13, 2008 at 3:39 AM, John Hamilton [EMAIL PROTECTED] wrote:
I'm trying to understand how short circuiting works with the Maybe monad.
Graham Fawcett wrote:
Yes, but that's still a 'quick' short-circuiting. In your example, if
'n' is Nothing, then the 'f = g = h' thunks will not be forced
(thanks to lazy evaluation), regardless of associativity. Tracing
verifies this:
No, it doesn't. What your tracing verifies is that the f,
I'm trying to understand how short circuiting works with the Maybe monad.
Take the expression n = f = g = h, which can be written as
(((n = f) = g) = h) because = is left associative. If n is
Nothing, this implies that (n = f) is Nothing, and so on, each nested
sub-expression easily evaluating to
13 matches
Mail list logo
