How suited are purely functional programming languages for I/O-intensive and database-related applications?

On Thu, 11 Jun 2009 16:40:09 +0200, Ertugrul Soylemez <es@ertes.de>
wrote:

>[...]
>
>That's completely wrong. One of the great advantages of immutability is
>recycling: If you have a large data structure and need a copy of it
>with only a tiny part changed, most of the structure is just reused. No
>copying involved. Have a look at Data.Map to see this in action. Based
>on Data.Map you can write a simple internal database server in a matter
>of a few lines. See the example code in [1].
>
>If your database server should exist throughout the entire lifetime of
>your application, you can get rid of quitAction and the Quit command,
>which saves some code, but usually there is no reason for that.
>
>As you see all code working with the database-internal Map is entirely
>pure. The 'modify' function of StateT takes the current state (the
>current Map in this case) and passes it to a pure function, which
>returns a new state. Yet no large copying is involved.
>
>[1] http://hpaste.org/fastcgi/hpaste.fcg...?id=5776#a5776
>
>
>> In particular, I would like to investigate his claim concerning
>> "Programs performing frequent I/O," since currently, my main interest
>> is in creating a virtual world using a collaborative multi-user online
>> virtual world application, such as Croquet (see
>> http://www.opencroquet.org/index.php/Main_Page) or Cobalt (see
>> http://www.duke.edu/~julian/Cobalt/Home.html). The challenge is to
>> create an massively multi-player online virtual world in a functional
>> programming language, because it seems that a multi-user online
>> virtual world application might be easier to write in a purely
>> object-oriented programming language such as Smalltalk, rather than in
>> a purely functional programming language, such as Haskell or Clean.
>
>Such a project requires good understanding of how to solve certain
>problems in Haskell or Clean. It's well possible, but as a beginner you
>may run into some problems because of language semantics, particularly
>if you're used to non-functional and/or strict languages.

The "non-functional" experience part shouldn't be an issue, since the
other main language in my programming language concept-space is
Scheme, which is a semi-functional language; however, the "strict"
part could be an issue there.

>> Would you agree or disagree with his claim regarding the relative
>> unsuitability of a purely functional programming language for
>> developing a collaborative multi-user online virtual world
>> application, which is I/O-intensive, and if so, why?
>
>I would disagree entirely. What is really missing in Haskell is some
>object-oriented constructs, but it should be easy to overcome this.

That would be nice, but is it really so? This is perhaps the gist of
the issue. Possible, yes, but easy?

To test my understanding, I'm going to see if it really works. Basing
the following example on the client-server example under "Using
Non-Object-Oriented Languages" in "What is Object-Oriented Software?
An Introduction" (see http://www.softwaredesign.com/objects.html),
suppose that I were running one process on a client and another
process on a server, and that the client-process and the
server-process were defining and communicating operations and
arguments to those operations in real-time. For concreteness, suppose
that the operation were '+', but that this operation were extended in
real-time on the client to include more and more types of arguments,
such as musical data, lists of inventory items for avatars, and even
gestures, with more definitions of '+' to be added in real-time by
users writing code on a client in real-time to be run on the server in
real-time.

If my understanding is correct, in a pure object-oriented language
such as Smalltalk, I could probably create a class on the client
called "gesture," as a subclass of another class "action" defined
separately, where "gesture" defines '+' as adding, say, a gesture of
an avatar (say, bowing) after a list of gestures to be executed
sequentially. For example:

a := Gesture fromAction: <some encoding for bowing>.
b := Gesture fromAction: <some encoding for waving>.
c := a + b.

Then c becomes a gesture for bowing followed by a gesture for waving,
to be executed on the server (which knew nothing about the definition
of '+' for gestures until receiving the definition of '+' for gestures
together with the definitions of gestures a and b).

The server then returns a gesture c which is a gesture for bowing
followed by a gesture for waving.

In Haskell, I would probably first think of using type classes to
extend types, but I am not sure whether type classes could be used on
a client in real-time to extend operations to be defined on new types
to be executed in real-time on a server.

Would this be easy to overcome without some object-oriented constructs
in Haskell?

>> (My intuition is that since a purely functional programming language
>> would try to preserve referential transparency, it would discourage
>> side-effects, which would be necessitated by most I/O (unless a
>> special mechanism to preserve functional purity were provided, such as
>> monads or uniqueness typing), whereas in a purely object-oriented
>> programming language, even atomic operations would be performed as
>> messages passed between objects, and that therefore, for this type of
>> application, a purely object-oriented programming language would be
>> better suited than a purely functional programming language, but I
>> could be wrong. If you think that my intuition is mistaken, please
>> explain your reasoning.)
>
>There is really nothing wrong with message passing and purity. One very
>useful concept is functional reactive programming (FRP). That's what
>you would typically use for a game server in Haskell. In FRP you
>describe the relative dependencies between objects with respect to time.

Thank you for the reference to FRP. I shall look up FRP and see
whether I can use it to to overcome various challenges in
client-server communication concerning objects.

-- Benjamin L. Russell
--
Benjamin L. Russell / DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile: +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto."
-- Matsuo Basho^

Today, I came across the following site (in Japanese) in which the
author made two claims about certain tasks that he believes that
purely functional programming languages are weak at. His claims are
interesting, and I would like to evaluate these claims through
discussion here:

Haskell $B$H$O(B ("About Haskell") [Japanese-language site]
http://www.shido.info/hs/haskell1.html

Specifically, he made the following claims concerning Haskell (after
describing that Haskell code is written so as to specify what value to
return):

>$B$3$N$3$H$+$i!"2<$G<($9$h$&$J<oN`$N%W%m%0%i%`$G $OM-8z$G$9!#(B
>
> * $B?tCM7W;;(B: Numerical Recipes $B$K:\$C$F$$$k$h$&$J%"%k%4%j%:%`!#(B
> * $BC5:w(B: $B5M$a>-4}$J$I$N7PO)$r5a$a$k$h$&$JLdBj!#(B
> * $B9=J82r@O(B: Haskell $B$N6H3&I8=`%3%s%Q%$%i!<(B GHC $B$O(B Haskell $B$G=q$+$l$F$$$k!#$^$?!"(B Perl6 $B$r(B Haskell $B$G=q$$$??M$,$$$k!#(B
>
>$B0lJ}!"0J2<$N<oN`$N%W%m%0%i%`$K$O8~$-$^$;$s!#=q$1$J$$$3$H$O$"$j$^$;$s$,!"(B $BB>$N8@8l$G=q$$$?$[$&$,3Z$G$7$g$&!#$^$?!"(BHaskell
$B$G$3$l$i$N%W%m%0%i%`$r=q$/$H!"(B $B<jB3$-7?8@8l$G=q$$$?$N$HF1$8$h$&$J%3!<%I$,=PMh>e$,$j$^$9 !#(B
>
> * $BIQHK$K(B IO $B$r9T$&%W%m%0%i%`(B: IO $B$J$I$NIT=c$J9T0Y$O(B Haskell $B$O6l<j!#(B
> * $BBg$-$J%G!<%?%Y!<%9$r07$&%W%m%0%i%`(B: Haskell $B$O=c?h$J4X?t7?$J$N$G!"%G!<%?%Y!<%9$r>/$7$7$+(B
$BJQ99$7$J$$$H$-$G$bA4BN$r99?7$9$kI,MW$,$"$k!#(BIO $B7?$N%G!<%?9=B$$r;H$($P$3$NLdBj$O2sHr$G$-$k$,!"(B $BC1=c$G$O$J$$!#(B

In translation, he claimed as follows:

>Therefore, it is valid for the following types of programs.
>
> * Numerical calculation: Algorithms such as those listed in Numerical Recipes.
> * Searching: Problems in which a path is to be obtained, such as the Shogi Mating Problem.
> * Parsing: Haskell's industry-standard compiler, GHC, is written in Haskell. Furthermore, there is a person who has
written Perl 6 in Haskell.
>
>On the other hand, it is not suited for the following types of programs. While these can still be written, it is probably
easier to write them in another language. Furthermore, if such programs are written in Haskell, code similar to that written
in a procedural language will result.
>
> * Programs performing frequent I/O: Haskell is weak at such impure behavior as I/O.
> * Programs handling a large database: Since Haskell is purely functional, even if only a small portion of a database
needs to be modified, there is a necessity to update the entirety. If an I/O-type data structure is used, this problem can
be avoided, but it is not simple.

In particular, I would like to investigate his claim concerning
"Programs performing frequent I/O," since currently, my main interest
is in creating a virtual world using a collaborative multi-user online
virtual world application, such as Croquet (see
http://www.opencroquet.org/index.php/Main_Page) or Cobalt (see
http://www.duke.edu/~julian/Cobalt/Home.html). The challenge is to
create an massively multi-player online virtual world in a functional
programming language, because it seems that a multi-user online
virtual world application might be easier to write in a purely
object-oriented programming language such as Smalltalk, rather than in
a purely functional programming language, such as Haskell or Clean.

Would you agree or disagree with his claim regarding the relative
unsuitability of a purely functional programming language for
developing a collaborative multi-user online virtual world
application, which is I/O-intensive, and if so, why?

(My intuition is that since a purely functional programming language
would try to preserve referential transparency, it would discourage
side-effects, which would be necessitated by most I/O (unless a
special mechanism to preserve functional purity were provided, such as
monads or uniqueness typing), whereas in a purely object-oriented
programming language, even atomic operations would be performed as
messages passed between objects, and that therefore, for this type of
application, a purely object-oriented programming language would be
better suited than a purely functional programming language, but I
could be wrong. If you think that my intuition is mistaken, please
explain your reasoning.)

-- Benjamin L. Russell
--
Benjamin L. Russell / DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile: +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto."
-- Matsuo Basho^

[Note: The previous message was correctly dated and was meant to
replace another previous message which had correct content but the
wrong date. However, the replacing message had the correct date but
incorrect content copied from the wrong message. Please replace both
messages with this message.]

On Thu, 11 Jun 2009 16:40:09 +0200, Ertugrul Soylemez <es@ertes.de>
wrote:

>[...]
>
>That's completely wrong. One of the great advantages of immutability is
>recycling: If you have a large data structure and need a copy of it
>with only a tiny part changed, most of the structure is just reused. No
>copying involved. Have a look at Data.Map to see this in action. Based
>on Data.Map you can write a simple internal database server in a matter
>of a few lines. See the example code in [1].
>
>If your database server should exist throughout the entire lifetime of
>your application, you can get rid of quitAction and the Quit command,
>which saves some code, but usually there is no reason for that.
>
>As you see all code working with the database-internal Map is entirely
>pure. The 'modify' function of StateT takes the current state (the
>current Map in this case) and passes it to a pure function, which
>returns a new state. Yet no large copying is involved.
>
>[1] http://hpaste.org/fastcgi/hpaste.fcg...?id=5776#a5776
>
>
>> In particular, I would like to investigate his claim concerning
>> "Programs performing frequent I/O," since currently, my main interest
>> is in creating a virtual world using a collaborative multi-user online
>> virtual world application, such as Croquet (see
>> http://www.opencroquet.org/index.php/Main_Page) or Cobalt (see
>> http://www.duke.edu/~julian/Cobalt/Home.html). The challenge is to
>> create an massively multi-player online virtual world in a functional
>> programming language, because it seems that a multi-user online
>> virtual world application might be easier to write in a purely
>> object-oriented programming language such as Smalltalk, rather than in
>> a purely functional programming language, such as Haskell or Clean.
>
>Such a project requires good understanding of how to solve certain
>problems in Haskell or Clean. It's well possible, but as a beginner you
>may run into some problems because of language semantics, particularly
>if you're used to non-functional and/or strict languages.

The "non-functional" experience part shouldn't be an issue, since the
other main language in my programming language concept-space is
Scheme, which is a semi-functional language; however, the "strict"
part could be an issue there.

>> Would you agree or disagree with his claim regarding the relative
>> unsuitability of a purely functional programming language for
>> developing a collaborative multi-user online virtual world
>> application, which is I/O-intensive, and if so, why?
>
>I would disagree entirely. What is really missing in Haskell is some
>object-oriented constructs, but it should be easy to overcome this.

That would be nice, but is it really so? This is perhaps the gist of
the issue. Possible, yes, but easy?

To test my understanding, I'm going to see if it really works. Basing
the following example on the client-server example under "Using
Non-Object-Oriented Languages" in "What is Object-Oriented Software?
An Introduction" (see http://www.softwaredesign.com/objects.html),
suppose that I were running one process on a client and another
process on a server, and that the client-process and the
server-process were defining and communicating operations and
arguments to those operations in real-time. For concreteness, suppose
that the operation were '+', but that this operation were extended in
real-time on the client to include more and more types of arguments,
such as musical data, lists of inventory items for avatars, and even
gestures, with more definitions of '+' to be added in real-time by
users writing code on a client in real-time to be run on the server in
real-time.

If my understanding is correct, in a pure object-oriented language
such as Smalltalk, I could probably create a class on the client
called "gesture," as a subclass of another class "action" defined
separately, where "gesture" defines '+' as adding, say, a gesture of
an avatar (say, bowing) after a list of gestures to be executed
sequentially. For example:

a := Gesture fromAction: <some encoding for bowing>.
b := Gesture fromAction: <some encoding for waving>.
c := a + b.

Then c becomes a gesture for bowing followed by a gesture for waving,
to be executed on the server (which knew nothing about the definition
of '+' for gestures until receiving the definition of '+' for gestures
together with the definitions of gestures a and b).

The server then returns a gesture c which is a gesture for bowing
followed by a gesture for waving.

In Haskell, I would probably first think of using type classes to
extend types, but I am not sure whether type classes could be used on
a client in real-time to extend operations to be defined on new types
to be executed in real-time on a server.

Would this be easy to overcome without some object-oriented constructs
in Haskell?

>> (My intuition is that since a purely functional programming language
>> would try to preserve referential transparency, it would discourage
>> side-effects, which would be necessitated by most I/O (unless a
>> special mechanism to preserve functional purity were provided, such as
>> monads or uniqueness typing), whereas in a purely object-oriented
>> programming language, even atomic operations would be performed as
>> messages passed between objects, and that therefore, for this type of
>> application, a purely object-oriented programming language would be
>> better suited than a purely functional programming language, but I
>> could be wrong. If you think that my intuition is mistaken, please
>> explain your reasoning.)
>
>There is really nothing wrong with message passing and purity. One very
>useful concept is functional reactive programming (FRP). That's what
>you would typically use for a game server in Haskell. In FRP you
>describe the relative dependencies between objects with respect to time.

Thank you for the reference to FRP. I shall look up FRP and see
whether I can use it to to overcome various challenges in
client-server communication concerning objects.

-- Benjamin L. Russell
--
Benjamin L. Russell / DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile: +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto."
-- Matsuo Basho^

Hello Benjamin,

Despite my recent gripes about Haskell I must say I do have a hard time
following this Japanese guys logic. Perhaps something's got lost in
translation?

Would Timber be of interest: http://www.timber-lang.org/

It's basically a Haskell derivative that has gone back to strict
semantics (sensibly IMO), but also a concurrent OO language based on
"reactive objects". It's also probably better suited to real time
applications as time semantics are part of the language and I believe
the plan is use "earliest deadline first" scheduling policy (which is
another good thing).

I think it's very early days for timber and there doesn't seem to be
proper document that even defines the language, so maybe it's not a
realistic option yet.

The other (bad) thing I would say is that AFAICS timbers design has also
been influenced by the all conquering "global variables are evil" meme
:-(

If I'm right about that side of Timber that seems like a shame, but as
it's still not documented properly I may well be wrong (might have
missed something).

Regards
--
Adrian Hey

On 11 Giu, 11:29, Benjamin L. Russell <DekuDekup...@Yahoo.com> wrote:
> Would you agree or disagree with his claim regarding the relative
> unsuitability of a purely functional programming language for
> developing a collaborative multi-user online virtual world
> application, which is I/O-intensive, and if so, why?

I agree.

While it's possible to do interactive I/O in purely functional
languages, it's not convenient.

Essentially it's a form of abstraction inversion: purely functional
languages abstract away the stateful nature of the underlaying system,
to produce a stateless functional system. IO monands or IO unique
objects reintroduce state on the top of the stateless functional
system.
They are a dirty hack, it's ok as long as you use them rarely, but if
you use them intensively then you are programmin in an ugly imperative
language implemented on top of a functional language.

Moreover, I'm not sure but I think that I/O sequencing using monads or
unique objects interacts poorly with concurrency, since you specify a
total ordering of I/O operations, while in many multi-user
applications only a partial ordering is required (I suppose it's
possible to implement partial ordering in purely functional languages,
but I don't know whether Haskell or Clean provide it).

Vend <vend82@virgilio.it> writes:
> Moreover, I'm not sure but I think that I/O sequencing using monads or
> unique objects interacts poorly with concurrency, since you specify a
> total ordering of I/O operations, while in many multi-user
> applications only a partial ordering is required (I suppose it's
> possible to implement partial ordering in purely functional languages,
> but I don't know whether Haskell or Clean provide it).

GHC has lightweight threads that are quite efficient, and parallelism
combinators that are simple to use.

Vend schrieb:
> On 11 Giu, 11:29, Benjamin L. Russell <DekuDekup...@Yahoo.com> wrote:
>> Would you agree or disagree with his claim regarding the relative
>> unsuitability of a purely functional programming language for
>> developing a collaborative multi-user online virtual world
>> application, which is I/O-intensive, and if so, why?
>
> I agree.
>
> While it's possible to do interactive I/O in purely functional
> languages, it's not convenient.
>
> Essentially it's a form of abstraction inversion: purely functional
> languages abstract away the stateful nature of the underlaying system,
> to produce a stateless functional system. IO monands or IO unique
> objects reintroduce state on the top of the stateless functional
> system.
> They are a dirty hack, it's ok as long as you use them rarely, but if
> you use them intensively then you are programmin in an ugly imperative
> language implemented on top of a functional language.

Or you just didn't understand the abstraction correctly, also you didn't
even bother to learn it properly before making such unfounded claims.
They are no dirty hack. They are a clean and very well-throught idea,
which is not only applicable to I/O. The state monads, which IO is
based on, is so convenient once you get used to it, that I have
implemented it in almost all languages (the ones, that support
parametric polymorphism) I'm using.

There are also many other monads like lists for non-deterministic code,
Maybe for a clean encoding of 'no result' (a special case of lists
actually), Cont for CPS-style code, possibly with escape continuations,
Parser (which is actually just a state monad) as a DSL for parsing
stuff, ST for pure destructive updates, etc.

Particularly interesting are monad transformers, which allow you to
combine monads arbitrarily. Stick together the list monad and a state
monad, then you've got non-deterministic state (code, which may have
multiple state/result threads). Stick together a CPS monad and IO, then
you've got IO with convenient continuations as well as call/cc.

Conclusion: Firstly monads are used a lot in Haskell and there is
nothing wrong with that, as they are very convenient both for elegance,
saving a lot of code and proving correctness. Also consider that most
languages support one or the other monad, just that they are named
differently, are far less convenient to use and you can't write your own
monads. Every code that uses exceptions actually executes in a CPS
monad. Haskell just makes them explicit.

Finally even Microsoft seems to disagree with you. They implemented
monads in F#, just that they don't give them the name 'monad'. As far
as I've seen, they didn't give them any name at all. Monadic
expressions are called 'computation expressions' or 'workflows' in F#.
Most people use those terms as aliases for monads.


> Moreover, I'm not sure but I think that I/O sequencing using monads or
> unique objects interacts poorly with concurrency, since you specify a
> total ordering of I/O operations, while in many multi-user
> applications only a partial ordering is required (I suppose it's
> possible to implement partial ordering in purely functional languages,
> but I don't know whether Haskell or Clean provide it).

That's what threads are good for. There is no language, which does not
sequence I/O operations. Haskell uses lightweight threads, as Paul
pointed out. Clean certainly supports something similar. The original
idea comes from Erlang, I believe. Inter-thread communication is done
through some convenient abstractions like MVars, Chans and semaphores,
possibly combined with STM, if you need it.


Greets,
Ertugrul.

On 16 Giu, 18:39, Ertugrul Söylemez <e...@ertes.de> wrote:
> Vend schrieb:
>
>
>
> > On 11 Giu, 11:29, Benjamin L. Russell <DekuDekup...@Yahoo.com> wrote:
> >> Would you agree or disagree with his claim regarding the relative
> >> unsuitability of a purely functional programming language for
> >> developing a collaborative multi-user online virtual world
> >> application, which is I/O-intensive, and if so, why?
>
> > I agree.
>
> > While it's possible to do interactive I/O in purely functional
> > languages, it's not convenient.
>
> > Essentially it's a form of abstraction inversion: purely functional
> > languages abstract away the stateful nature of the underlaying system,
> > to produce a stateless functional system. IO monands or IO unique
> > objects reintroduce state on the top of the stateless functional
> > system.
> > They are a dirty hack, it's ok as long as you use them rarely, but if
> > you use them intensively then you are programmin in an ugly imperative
> > language implemented on top of a functional language.
>
> Or you just didn't understand the abstraction correctly, also you didn't
> even bother to learn it properly before making such unfounded claims.
> They are no dirty hack. *They are a clean and very well-throught idea,
> which is not only applicable to I/O. *The state monads, which IO is
> based on, is so convenient once you get used to it, that I have
> implemented it in almost all languages (the ones, that support
> parametric polymorphism) I'm using.

Or you could just try to read for comprehension.
I didn't claim that monads are hacks. I claimed that I/O monads are
hacks.

<snip irrelevant stuff>

> > Moreover, I'm not sure but I think that I/O sequencing using monads or
> > unique objects interacts poorly with concurrency, since you specify a
> > total ordering of I/O operations, while in many multi-user
> > applications only a partial ordering is required (I suppose it's
> > possible to implement partial ordering in purely functional languages,
> > but I don't know whether Haskell or Clean provide it).
>
> That's what threads are good for. *There is no language, which does not
> sequence I/O operations. *Haskell uses lightweight threads, as Paul
> pointed out. *Clean certainly supports something similar. *The original
> idea comes from Erlang, I believe. *Inter-thread communication is done
> through some convenient abstractions like MVars, Chans and semaphores,
> possibly combined with STM, if you need it.

Ok.

Ertugrul Söylemez wrote:
> Vend <vend82@virgilio.it> wrote:
>> I didn't claim that monads are hacks. I claimed that I/O monads are
>> hacks.
>
> Same thing: Still wrong.

Adrian Hey wrote:
> Ertugrul Söylemez wrote:
>> Vend <vend82@virgilio.it> wrote:
>>> I didn't claim that monads are hacks. I claimed that I/O monads are
>>> hacks.
>>
>> Same thing: Still wrong.

Whoops, hit send before I'd written anything...

Describing IO monad as dirty hack is probably a bit OTT. As
formalisation of good old fashioned procedural programming it
works OK, more or less. But therein lies the problem too, which is what
Vend is getting at. Why should IO be done this way?

Using a monad does over determine execution order. This is the objection
of the Clean designers. I don't personally agree with their solution
of "deterministic concurrency", but the objection is a valid one IMO.

The idea of "threads" sequencing potentially blocking IO operations and
the use of forkIO as workaround for the inherent "sequentiality" of all
this seems pretty ugly to me too. The ideas behind O'Haskell and now
Timber are much more appealing.

Regards
--
Adrian Hey

Adrian Hey <ahey@NoSpicedHam.iee.org> writes:
> Using a monad does over determine execution order. This is the objection
> of the Clean designers.

Oleg also says something like that:
http://lambda-the-ultimate.org/node/2749#comment-41078

On 16 Giu, 20:26, Ertugrul Söylemez <e...@ertes.de> wrote:
> Vend <ven...@virgilio.it> wrote:
> > > Or you just didn't understand the abstraction correctly, also you
> > > didn't even bother to learn it properly before making such unfounded
> > > claims. *They are no dirty hack. *They are a clean and very
> > > well-throught idea, which is not only applicable to I/O. *The state
> > > monads, which IO is based on, is so convenient once you get used to
> > > it, that I have implemented it in almost all languages (the ones,
> > > that support parametric polymorphism) I'm using.
>
> > Or you could just try to read for comprehension.
> > I didn't claim that monads are hacks. I claimed that I/O monads are
> > hacks.
>
> Same thing: *Still wrong.

Unsupported assertion.

Vend wrote:
> On 16 Giu, 20:26, Ertugrul Söylemez <e...@ertes.de> wrote:
>> Vend <ven...@virgilio.it> wrote:
>> > > Or you just didn't understand the abstraction correctly, also you
>> > > didn't even bother to learn it properly before making such unfounded
>> > > claims. Â*They are no dirty hack. Â*They are a clean and very
>> > > well-throught idea, which is not only applicable to I/O. Â*The state
>> > > monads, which IO is based on, is so convenient once you get used to
>> > > it, that I have implemented it in almost all languages (the ones,
>> > > that support parametric polymorphism) I'm using.
>>
>> > Or you could just try to read for comprehension.
>> > I didn't claim that monads are hacks. I claimed that I/O monads are
>> > hacks.
>>
>> Same thing: Â*Still wrong.
>
> Unsupported assertion.

I don't know if you've noticed but Ertugrul is still posting noob questions.
You might want to take his authoritative-sounding stances with regard to
non-trivial subjects with a pinch of salt...

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

Ertugrul Söylemez <es@ertes.de> writes:
> There is some truth about 'overdetermining' execution order. However, I
> don't think this is a problem related to monads in general, but to the
> IO monad. State monads, for example, are as pure (and therefore as
> non-strict) as non-monadic code.

I thought that the whole invention of arrows had something to do with
certain monadic parsing schemes being inefficient because of that
overdetermination.

Paul Rubin schrieb:
> Ertugrul Söylemez <es@ertes.de> writes:
>> There is some truth about 'overdetermining' execution order. However, I
>> don't think this is a problem related to monads in general, but to the
>> IO monad. State monads, for example, are as pure (and therefore as
>> non-strict) as non-monadic code.
>
> I thought that the whole invention of arrows had something to do with
> certain monadic parsing schemes being inefficient because of that
> overdetermination.

The problem with the usual monadic approach in parsing is late failing.
Consider a parser for numeric words 'one', 'two' and 'three'. A
monadic parser would try to parse 'one', fail, then 'two', fail, then
'three'. An arrow parser can fail already by finding that the first
character is neither 'o', nor 't'. It could sort out 'one' by finding
that the first character is a 't'. That saves a lot of backtracking.

You can build such a more intelligent parser with monads, too, but it
requires more work. Arrows make it much easier.


Greets,
Ertugrul.