-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Richard,
On Tuesday 19 February 2002 06:57, Richard Uhtenwoldt wrote:
This is a weak argument.
First of all it is not the case that imperative coders always specify a
total ordering: multitasking, threading and interrupts (and their
Artie Gold writes:
One way to think of it is to look at a program as a partially ordered
set of calculations; some calculations need to occur before others,
other groups can occur in any order. In an imperative language you
specify a total ordering (which is overkill).
This is a weak argument.
I agree with others who mentioned that viewing monads as simply
providing a way to sequentialize things or to program imperatively is
the wrong way to look at them.
snip
Yes, Lists are the classical example.
That said, the EFFICIENCY of monads is often poorly understood. To
state the
Eric Allen Wohlstadter wrote:
I see a lot of literature that says that monads simulate the effects of
imperative programming concepts. It seems to me that the relative
performance of monadic implementations must be equivalant to imperative
ones to provide a strong case for functional
I see a lot of literature that says that monads simulate the effects of
imperative programming concepts.
I think that's just bad wording. To take a rather trite
point of view, in a language such as C /everything/ is done
within a monad, and all types, even int, are really IO
something (IO
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Let me offer a differing view of Monads.
Monads are a way to write type-safe imperative programs within a functional
framework. It's just an advanced version of PROGN kludge in LISP.
Since they are based on a linear flow of commands, they seem to
Eray Ozkural (exa) wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Let me offer a differing view of Monads.
Monads are a way to write type-safe imperative programs within a functional
framework. It's just an advanced version of PROGN kludge in LISP.
Since they are based on a
