functional/immutable programming question

if every client just gets the current list and adds an element, i'll have a "hydra" (list with many heads and one tail), so as far as i understand it there has to be some state in the program where the new head replaced the old head. otherwise, the second caller has no way to access the current head of the list, it'll just get the initial one.

-------- Original-Nachricht --------
> Datum: Thu, 11 Nov 2010 10:45:52 +0100
> Von: "Dennis Haupt"
> An: scala-user@listes.epfl.ch
> Betreff: [scala-user] functional/immutable programming question

> in pure functional programming, there are no side effects. this means, the
> only "effect" a method has is its returned value, right? it doesn't hold a
> mutable state.
>
> if so, how do i implement something that HAS to hold a state? what if
> let's say 10 clients try to add elements to the same list instance? there has
> to be a managing class that holds the list, right?
>
>

In a pure language the 'something' holding the state would be a state
or writer monad.

Of course if this were a proper client-server environment you would
need to have some impurity or else your program would never be able to
handle non-determinism.

-Rob

On Thu, Nov 11, 2010 at 9:45 AM, Dennis Haupt wrote:
> in pure functional programming, there are no side effects. this means, the only "effect" a method has is its returned value, right? it doesn't hold a mutable state.
>
> if so, how do i implement something that HAS to hold a state? what if let's say 10 clients try to add elements to the same list instance? there has to be a managing class that holds the list, right?
>
>
> --
> GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit
> gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl
>

what is a state monad?

-------- Original-Nachricht --------
> Datum: Thu, 11 Nov 2010 09:53:56 +0000
> Von: Robert Wills
> An: Dennis Haupt
> CC: scala-user@listes.epfl.ch
> Betreff: Re: [scala-user] functional/immutable programming question

> In a pure language the 'something' holding the state would be a state
> or writer monad.
>
> Of course if this were a proper client-server environment you would
> need to have some impurity or else your program would never be able to
> handle non-determinism.
>
> -Rob
>
> On Thu, Nov 11, 2010 at 9:45 AM, Dennis Haupt wrote:
> > in pure functional programming, there are no side effects. this means,
> the only "effect" a method has is its returned value, right? it doesn't hold
> a mutable state.
> >
> > if so, how do i implement something that HAS to hold a state? what if
> let's say 10 clients try to add elements to the same list instance? there has
> to be a managing class that holds the list, right?
> >
> >
> > --
> > GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit
> > gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl
> >

It's like the IO monad but a little different ;)

Thanks,
Razvan

On 2010-11-11, at 5:00 AM, "Dennis Haupt" wrote:

> what is a state monad?
>
> -------- Original-Nachricht --------
>> Datum: Thu, 11 Nov 2010 09:53:56 +0000
>> Von: Robert Wills
>> An: Dennis Haupt
>> CC: scala-user@listes.epfl.ch
>> Betreff: Re: [scala-user] functional/immutable programming question
>
>> In a pure language the 'something' holding the state would be a state
>> or writer monad.
>>
>> Of course if this were a proper client-server environment you would
>> need to have some impurity or else your program would never be able to
>> handle non-determinism.
>>
>> -Rob
>>
>> On Thu, Nov 11, 2010 at 9:45 AM, Dennis Haupt wrote:
>>> in pure functional programming, there are no side effects. this means,
>> the only "effect" a method has is its returned value, right? it doesn't hold
>> a mutable state.
>>>
>>> if so, how do i implement something that HAS to hold a state? what if
>> let's say 10 clients try to add elements to the same list instance? there has
>> to be a managing class that holds the list, right?
>>>
>>>
>>> --
>>> GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit
>>> gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl
>>>
>

fp and immutable data structures are celebrated as solving all problems, but as you see, they don't, in particular they have no clear concept of dynamicity, so things that change over time. they don't solve your problem of concurrent access here, so you will need to linearize your clients in some way. for example, you could manage them with an Actor or use an STM... immutable structures and STM play nicely together, as when a transaction is aborted you haven't crippled your data structure, just the newly created copy (old list plus new head element, for instance) isn't stored in the ref, no damage is done.

best, -sciss-

Am 11.11.2010 um 09:45 schrieb Dennis Haupt:

> in pure functional programming, there are no side effects. this means, the only "effect" a method has is its returned value, right? it doesn't hold a mutable state.
>
> if so, how do i implement something that HAS to hold a state? what if let's say 10 clients try to add elements to the same list instance? there has to be a managing class that holds the list, right?
>
>

sciss is right. Pure fp doesn't solve all your problems and there is
inevitably going to be some point of your program which is impure.
Things like the State monad help ensure that that purity is isolated
in one part of your program. Haskell programs generally keep all the
'dynamic' or non-deterministic stuff in one part of the program by
using a stack of monads and other pointy-headed stuff. Arguably, this
can make them hard to understand but it does make them very safe and
very easily testable.

I'm not sure if I'm on top of all the terminology or the concepts but
I think there are two issues here: one is purity and the other is
concurrency. STM and actors help with the latter. Monads help with
the former.

Thinking again about the example you describe the STM and actors would
be more useful there -- actors for handling the clients and stm for
handling access to the list. If however you had a complicated
computation that needed to manipulate some common piece of data you
could use a state monad there to provide pure access to the data
without having to thread the state through your entire computation.

-Rob

On Thu, Nov 11, 2010 at 12:30 PM, Sciss wrote:
> fp and immutable data structures are celebrated as solving all problems, but as you see, they don't, in particular they have no clear concept of dynamicity, so things that change over time. they don't solve your problem of concurrent access here, so you will need to linearize your clients in some way. for example, you could manage them with an Actor or use an STM... immutable structures and STM play nicely together, as when a transaction is aborted you haven't crippled your data structure, just the newly created copy (old list plus new head element, for instance) isn't stored in the ref, no damage is done.
>
> best, -sciss-
>
>
> Am 11.11.2010 um 09:45 schrieb Dennis Haupt:
>
>> in pure functional programming, there are no side effects. this means, the only "effect" a method has is its returned value, right? it doesn't hold a mutable state.
>>
>> if so, how do i implement something that HAS to hold a state? what if let's say 10 clients try to add elements to the same list instance? there has to be a managing class that holds the list, right?
>>
>>
>> --
>> GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit
>> gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl
>
>

i can imagine programming everything using only immutable objects/structs/values as long as there is one *mutable* entry point for the current complete world which i then navigate through.

for example, in tetris, there's a board. i can easily do:
val newBoard = oldBoard.withUserMove(move)
to execute a single move and get the resulting board.

but to make the game run forever, i need at least ONE global mutable state do be able to do this:

var myMostRecentWorld = new Board
while (true) {
myMostRecentWorld = myMostRecentWorld.withUserMove(getMoveFromSomeWhere)
}

if i try to avoid even that mutable state, i can only come up with *really* weird stuff like

def advanceOneStep(world:Board) {
advanceOneStep(world.withUserMove(getMoveFromSomeWhere)
}

which will eventually lead to a stackoverflow or outofmemory

how does the state/io-monad work? like my "var currentWorld"?

-------- Original-Nachricht --------
> Datum: Thu, 11 Nov 2010 07:27:34 -0500
> Von: Razvan Cojocaru
> An: Dennis Haupt
> CC: Robert Wills , "scala-user@listes.epfl.ch"
> Betreff: Re: [scala-user] functional/immutable programming question

> It's like the IO monad but a little different ;)
>
> Thanks,
> Razvan
>
> On 2010-11-11, at 5:00 AM, "Dennis Haupt" wrote:
>
> > what is a state monad?
> >
> > -------- Original-Nachricht --------
> >> Datum: Thu, 11 Nov 2010 09:53:56 +0000
> >> Von: Robert Wills
> >> An: Dennis Haupt
> >> CC: scala-user@listes.epfl.ch
> >> Betreff: Re: [scala-user] functional/immutable programming question
> >
> >> In a pure language the 'something' holding the state would be a state
> >> or writer monad.
> >>
> >> Of course if this were a proper client-server environment you would
> >> need to have some impurity or else your program would never be able to
> >> handle non-determinism.
> >>
> >> -Rob
> >>
> >> On Thu, Nov 11, 2010 at 9:45 AM, Dennis Haupt wrote:
> >>> in pure functional programming, there are no side effects. this means,
> >> the only "effect" a method has is its returned value, right? it doesn't
> hold
> >> a mutable state.
> >>>
> >>> if so, how do i implement something that HAS to hold a state? what if
> >> let's say 10 clients try to add elements to the same list instance?
> there has
> >> to be a managing class that holds the list, right?
> >>>
> >>>
> >>> --
> >>> GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit
> >>> gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl
> >>>
> >
> > --
> > GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit
> > gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl

Robert Wills wrote:
> sciss is right. Pure fp doesn't solve all your problems and there is
> inevitably going to be some point of your program which is impure.
> Things like the State monad help ensure that that purity is isolated
> in one part of your program. Haskell programs generally keep all the
> 'dynamic' or non-deterministic stuff in one part of the program by
> using a stack of monads and other pointy-headed stuff. Arguably, this
> can make them hard to understand but it does make them very safe and
> very easily testable.

I think either you or me are confusing concepts here, so please bear
with me:

In my understanding, IO monad and the like are exactly for keeping
impurity out of your program. That's exactly why Haskell uses monads for
IO etc. So as long as you use monads for the dynamic parts, you're still
pure. The way to introduce impurity in Haskell would be "unsafe"
functions (unsafeIO etc.) which again can only be called from unsafe
functions (?). Am I missing something?

Am Donnerstag, den 11.11.2010, 14:04 +0100 schrieb "Dennis Haupt"
:
> i can imagine programming everything using only immutable
> objects/structs/values as long as there is one *mutable* entry point
> for the current complete world which i then navigate through.

I found James Iry's blog a good read for that topic:
http://james-iry.blogspot.com/2007/11/monads-are-elephants-part-4.html

(this part introduces the IO monad, the basics are in part 1-3, linked
from the above page)

Kind regards
Andreas

The first approximation for a state monad is an entity that wraps a state.
You can only change the state that's inside the monad, by passing the monad
a function that changes the state and then let the monad invoke your
function and change the state accordingly.

If you think of it that way, the state itself is never visible outside the
monad (or it doesn't have to be). That's how you guarantee that nobody can
mess with it outside of the monad's control.

A monad is really an extension to something like this:

atomically (f,g) = { // simplified STM monad
lockandstarttransaction
var v = readoldvalue
v = f (v)
v = g (v)
setnewvalue (v)
unlockandendtransaction
}

As you see, the actual value never escapes the "monad"...

The mathematics behind it, the scala syntax (for comprehension) and the
actual function signatures are a little more complicated, to allow
composition, but this is the general idea...

scalaz has a state monad, here's a good post on that:
http://blog.tmorris.net/the-state-monad-for-scala-users/

here's an (complex) example of using the scalaz.State monad:
https://github.com/scalaz/scalaz/blob/master/example/src/main/scala/scal...

good luck!
Razvan

-----Original Message-----
From: Dennis Haupt
Sent: Thursday, November 11, 2010 8:04 AM
To: Razvan Cojocaru
Cc: scala-user@listes.epfl.ch ; wrwills@gmail.com
Subject: Re: [scala-user] functional/immutable programming question

i can imagine programming everything using only immutable
objects/structs/values as long as there is one *mutable* entry point for the
current complete world which i then navigate through.

for example, in tetris, there's a board. i can easily do:
val newBoard = oldBoard.withUserMove(move)
to execute a single move and get the resulting board.

but to make the game run forever, i need at least ONE global mutable state
do be able to do this:

var myMostRecentWorld = new Board
while (true) {
myMostRecentWorld = myMostRecentWorld.withUserMove(getMoveFromSomeWhere)
}

if i try to avoid even that mutable state, i can only come up with *really*
weird stuff like

def advanceOneStep(world:Board) {
advanceOneStep(world.withUserMove(getMoveFromSomeWhere)
}

which will eventually lead to a stackoverflow or outofmemory

how does the state/io-monad work? like my "var currentWorld"?

-------- Original-Nachricht --------
> Datum: Thu, 11 Nov 2010 07:27:34 -0500
> Von: Razvan Cojocaru
> An: Dennis Haupt
> CC: Robert Wills , "scala-user@listes.epfl.ch"
>
> Betreff: Re: [scala-user] functional/immutable programming question

> It's like the IO monad but a little different ;)
>
> Thanks,
> Razvan
>
> On 2010-11-11, at 5:00 AM, "Dennis Haupt" wrote:
>
> > what is a state monad?
> >
> > -------- Original-Nachricht --------
> >> Datum: Thu, 11 Nov 2010 09:53:56 +0000
> >> Von: Robert Wills
> >> An: Dennis Haupt
> >> CC: scala-user@listes.epfl.ch
> >> Betreff: Re: [scala-user] functional/immutable programming question
> >
> >> In a pure language the 'something' holding the state would be a state
> >> or writer monad.
> >>
> >> Of course if this were a proper client-server environment you would
> >> need to have some impurity or else your program would never be able to
> >> handle non-determinism.
> >>
> >> -Rob
> >>
> >> On Thu, Nov 11, 2010 at 9:45 AM, Dennis Haupt wrote:
> >>> in pure functional programming, there are no side effects. this means,
> >> the only "effect" a method has is its returned value, right? it doesn't
> hold
> >> a mutable state.
> >>>
> >>> if so, how do i implement something that HAS to hold a state? what if
> >> let's say 10 clients try to add elements to the same list instance?
> there has
> >> to be a managing class that holds the list, right?
> >>>
> >>>
> >>> --
> >>> GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit
> >>> gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl
> >>>
> >
> > --
> > GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit
> > gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl

The first approximation for a state monad is an entity that wraps a state.
You can only change the state that's inside the monad, by passing the monad
a function that changes the state and then let the monad invoke your
function and change the state accordingly.

If you think of it that way, the state itself is never visible outside the
monad (or it doesn't have to be). That's how you guarantee that nobody can
mess with it outside of the monad's control.

A monad is really an extension to something like this:

atomically (f,g) = { // simplified STM monad
lockandstarttransaction
var v = readoldvalue
v = f (v)
v = g (v)
setnewvalue (v)
unlockandendtransaction
}

As you see, the actual value never escapes the "monad"...

The mathematics behind it, the scala syntax (for comprehension) and the
actual function signatures are a little more complicated, to allow
composition, but this is the general idea...

scalaz has a state monad, here's a good post on that:
http://blog.tmorris.net/the-state-monad-for-scala-users/

here's an (complex) example of using the scalaz.State monad:
https://github.com/scalaz/scalaz/blob/master/example/src/main/scala/scal...

good luck!
Razvan

-----Original Message-----
From: Dennis Haupt
Sent: Thursday, November 11, 2010 8:04 AM
To: Razvan Cojocaru
Cc: scala-user@listes.epfl.ch ; wrwills@gmail.com
Subject: Re: [scala-user] functional/immutable programming question

i can imagine programming everything using only immutable
objects/structs/values as long as there is one *mutable* entry point for the
current complete world which i then navigate through.

for example, in tetris, there's a board. i can easily do:
val newBoard = oldBoard.withUserMove(move)
to execute a single move and get the resulting board.

but to make the game run forever, i need at least ONE global mutable state
do be able to do this:

var myMostRecentWorld = new Board
while (true) {
myMostRecentWorld = myMostRecentWorld.withUserMove(getMoveFromSomeWhere)
}

if i try to avoid even that mutable state, i can only come up with *really*
weird stuff like

def advanceOneStep(world:Board) {
advanceOneStep(world.withUserMove(getMoveFromSomeWhere)
}

which will eventually lead to a stackoverflow or outofmemory

how does the state/io-monad work? like my "var currentWorld"?

-------- Original-Nachricht --------
> Datum: Thu, 11 Nov 2010 07:27:34 -0500
> Von: Razvan Cojocaru
> An: Dennis Haupt
> CC: Robert Wills , "scala-user@listes.epfl.ch"
>
> Betreff: Re: [scala-user] functional/immutable programming question

> It's like the IO monad but a little different ;)
>
> Thanks,
> Razvan
>
> On 2010-11-11, at 5:00 AM, "Dennis Haupt" wrote:
>
> > what is a state monad?
> >
> > -------- Original-Nachricht --------
> >> Datum: Thu, 11 Nov 2010 09:53:56 +0000
> >> Von: Robert Wills
> >> An: Dennis Haupt
> >> CC: scala-user@listes.epfl.ch
> >> Betreff: Re: [scala-user] functional/immutable programming question
> >
> >> In a pure language the 'something' holding the state would be a state
> >> or writer monad.
> >>
> >> Of course if this were a proper client-server environment you would
> >> need to have some impurity or else your program would never be able to
> >> handle non-determinism.
> >>
> >> -Rob
> >>
> >> On Thu, Nov 11, 2010 at 9:45 AM, Dennis Haupt wrote:
> >>> in pure functional programming, there are no side effects. this means,
> >> the only "effect" a method has is its returned value, right? it doesn't
> hold
> >> a mutable state.
> >>>
> >>> if so, how do i implement something that HAS to hold a state? what if
> >> let's say 10 clients try to add elements to the same list instance?
> there has
> >> to be a managing class that holds the list, right?
> >>>
> >>>
> >>> --
> >>> GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit
> >>> gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl
> >>>
> >
> > --
> > GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit
> > gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl

yay, something to read :D

-------- Original-Nachricht --------
> Datum: Thu, 11 Nov 2010 08:55:48 -0500
> Von: "Razvan Cojocaru"
> An: "Dennis Haupt"
> CC: scala-user@listes.epfl.ch, wrwills@gmail.com
> Betreff: Re: [scala-user] functional/immutable programming question

> The first approximation for a state monad is an entity that wraps a state.
> You can only change the state that's inside the monad, by passing the
> monad
> a function that changes the state and then let the monad invoke your
> function and change the state accordingly.
>
> If you think of it that way, the state itself is never visible outside the
> monad (or it doesn't have to be). That's how you guarantee that nobody can
> mess with it outside of the monad's control.
>
> A monad is really an extension to something like this:
>
> atomically (f,g) = { // simplified STM monad
> lockandstarttransaction
> var v = readoldvalue
> v = f (v)
> v = g (v)
> setnewvalue (v)
> unlockandendtransaction
> }
>
> As you see, the actual value never escapes the "monad"...
>
> The mathematics behind it, the scala syntax (for comprehension) and the
> actual function signatures are a little more complicated, to allow
> composition, but this is the general idea...
>
> scalaz has a state monad, here's a good post on that:
> http://blog.tmorris.net/the-state-monad-for-scala-users/
>
> here's an (complex) example of using the scalaz.State monad:
> https://github.com/scalaz/scalaz/blob/master/example/src/main/scala/scal...
>
> good luck!
> Razvan
>
>
> -----Original Message-----
> From: Dennis Haupt
> Sent: Thursday, November 11, 2010 8:04 AM
> To: Razvan Cojocaru
> Cc: scala-user@listes.epfl.ch ; wrwills@gmail.com
> Subject: Re: [scala-user] functional/immutable programming question
>
> i can imagine programming everything using only immutable
> objects/structs/values as long as there is one *mutable* entry point for
> the
> current complete world which i then navigate through.
>
> for example, in tetris, there's a board. i can easily do:
> val newBoard = oldBoard.withUserMove(move)
> to execute a single move and get the resulting board.
>
> but to make the game run forever, i need at least ONE global mutable state
> do be able to do this:
>
> var myMostRecentWorld = new Board
> while (true) {
> myMostRecentWorld =
> myMostRecentWorld.withUserMove(getMoveFromSomeWhere)
> }
>
> if i try to avoid even that mutable state, i can only come up with
> *really*
> weird stuff like
>
> def advanceOneStep(world:Board) {
> advanceOneStep(world.withUserMove(getMoveFromSomeWhere)
> }
>
> which will eventually lead to a stackoverflow or outofmemory
>
> how does the state/io-monad work? like my "var currentWorld"?
>
>
> -------- Original-Nachricht --------
> > Datum: Thu, 11 Nov 2010 07:27:34 -0500
> > Von: Razvan Cojocaru
> > An: Dennis Haupt
> > CC: Robert Wills , "scala-user@listes.epfl.ch"
> >
> > Betreff: Re: [scala-user] functional/immutable programming question
>
> > It's like the IO monad but a little different ;)
> >
> > Thanks,
> > Razvan
> >
> > On 2010-11-11, at 5:00 AM, "Dennis Haupt" wrote:
> >
> > > what is a state monad?
> > >
> > > -------- Original-Nachricht --------
> > >> Datum: Thu, 11 Nov 2010 09:53:56 +0000
> > >> Von: Robert Wills
> > >> An: Dennis Haupt
> > >> CC: scala-user@listes.epfl.ch
> > >> Betreff: Re: [scala-user] functional/immutable programming question
> > >
> > >> In a pure language the 'something' holding the state would be a state
> > >> or writer monad.
> > >>
> > >> Of course if this were a proper client-server environment you would
> > >> need to have some impurity or else your program would never be able
> to
> > >> handle non-determinism.
> > >>
> > >> -Rob
> > >>
> > >> On Thu, Nov 11, 2010 at 9:45 AM, Dennis Haupt wrote:
> > >>> in pure functional programming, there are no side effects. this
> means,
> > >> the only "effect" a method has is its returned value, right? it
> doesn't
> > hold
> > >> a mutable state.
> > >>>
> > >>> if so, how do i implement something that HAS to hold a state? what
> if
> > >> let's say 10 clients try to add elements to the same list instance?
> > there has
> > >> to be a managing class that holds the list, right?
> > >>>
> > >>>
> > >>> --
> > >>> GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit
> > >>> gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl
> > >>>
> > >
> > > --
> > > GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit
> > > gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl
>

> if i try to avoid even that mutable state, i can only come up with
> *really* weird stuff like
>
> def advanceOneStep(world:Board) {
> advanceOneStep(world.withUserMove(getMoveFromSomeWhere)
> }
>
> which will eventually lead to a stackoverflow or outofmemory

Why?

I mean, when talking about pure functional things, you are also
talking about tail recursion, and the solution above seems to
be one in my eyes.
With tail-call-optimization there shouldn't be any memory problems
so far for this simple example.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/11/10 22:30, Sciss wrote:
> fp and immutable data structures are celebrated as solving all
> problems, but as you see, they don't, in particular they have no
> clear concept of dynamicity, so things that change over time. they
> don't solve your problem of concurrent access here, so you will
> need to linearize your clients in some way. for example, you could
> manage them with an Actor or use an STM... immutable structures and
> STM play nicely together, as when a transaction is aborted you
> haven't crippled your data structure, just the newly created copy
> (old list plus new head element, for instance) isn't stored in the
> ref, no damage is done.
>
> best, -sciss-
Beware, nonsense lurks there.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/11/10 20:00, Dennis Haupt wrote:
> what is a state monad?
>
Given: case class State[S, A](f: S => (S, A))

object StateMonad {
def bind[A, B](s: State[S, A], f: A => State[S, B]): State[S, B] =
error("todo")

def pure[S, A](a: => A): State[S, A] = error("todo")
}

The monad is the implementation of the two functions above satisfying
left/right identity for pure and associativity for bind.

PS: I'd like to also point out that this discussion has absolutely
nothing to do with monads and existence otherwise is a (common)
symptom of failing to identify essentials. Expect a lot of mythology
floating passed your inbox.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/11/10 23:12, Andreas Flierl wrote:
>
> Robert Wills wrote:
>> sciss is right.  Pure fp doesn't solve all your problems and
>> there is inevitably going to be some point of your program which
>> is impure. Things like the State monad help ensure that that
>> purity is isolated in one part of your program.  Haskell
>> programs generally keep all the 'dynamic' or non-deterministic
>> stuff in one part of the program by using a stack of monads and
>> other pointy-headed stuff.  Arguably, this can make them hard to
>> understand but it does make them very safe and very easily
>> testable.
>
> I think either you or me are confusing concepts here, so please
> bear with me:
>
> In my understanding, IO monad and the like are exactly for keeping
>  impurity out of your program. That's exactly why Haskell uses
> monads for IO etc. So as long as you use monads for the dynamic
> parts, you're still pure. The way to introduce impurity in Haskell
> would be "unsafe" functions (unsafeIO etc.) which again can only
> be called from unsafe functions (?). Am I missing something?
No you are not missing anything. You are completely correct with one
minor caveat.

In this discussion, we are not referring to the IO
monad (except when we misidentify) but the IO type constructor.

I strongly advise against using the irrelevant term "monad" for this
purpose. Here's why.

IO is also:
* an applicative functor
* a pointed functor
* a covariant functor
* a monoid
* many other things

Notice we are not saying "the IO applicative functor." That's because
it is irrelevant -- just as irrelevant as using the term monad. The
term monad gets much more attention than it deserves. This attention
has a *detrimental effect* on people trying to learn, because they
too, will wonder about the relevance as they try to form a concept.

In this discussion, we are talking about the IO type constructor or
perhaps IO values, but I've not seen any valid reference to the IO
monad or the IO functor or any other thing that continues to be
irrelevant.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/11/10 00:14, Dennis Haupt wrote:
> yay, something to read :D

Let me know if you have questions. (I wrote the mentioned scalaz data
structure and the blog post).

beware, your comments are a waste of time. if you want to help in this thread, break down your superior knowledge in a way that it is shared with others, and explain why something is nonsense in your opinion.

Am 11.11.2010 um 20:29 schrieb Tony Morris:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 11/11/10 22:30, Sciss wrote:
>> fp and immutable data structures are celebrated as solving all
>> problems, but as you see, they don't, in particular they have no
>> clear concept of dynamicity, so things that change over time. they
>> don't solve your problem of concurrent access here, so you will
>> need to linearize your clients in some way. for example, you could
>> manage them with an Actor or use an STM... immutable structures and
>> STM play nicely together, as when a transaction is aborted you
>> haven't crippled your data structure, just the newly created copy
>> (old list plus new head element, for instance) isn't stored in the
>> ref, no damage is done.
>>
>> best, -sciss-
> Beware, nonsense lurks there.
>
> - --
> Tony Morris
> http://tmorris.net/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkzcUkAACgkQmnpgrYe6r616mwCgr4kl31vSxo36XwH70Jt71d1z
> 9tcAnii11F1SLyI/XOiFNLNUOUelyzZu
> =3FTH
> -----END PGP SIGNATURE-----
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alas, if I were to respond to every bit of nonsense on the internet,
I'd be very busy indeed! Further, your particular misunderstanding is:

a) Extremely common
b) Extremely difficult (for me anyway) to demonstrate for a general
audience. I have done so successfully many times, but only with full
attention being given to the topic one-on-one.

Instead of addressing nonsense of this particular magnitude, I
request, in the most polite manner possible, the following: Stop
talking shit. In response, I will go to extraordinary efforts to do
same, nevertheless acknowledging both of our fallibility.

Sound fair? If not, where do I begin unravelling your fallacious
comments? It's an honest question -- despite your unawareness of
falsehood, I simply don't know where to begin.

Do you honestly believe that first sentence? Do you care to put a bit
more thought into it? I'm don't intend to be a dick, just prevent the
misguidance of others. Be nice to noobs -- you don't yet know how hard
it is to help them out after they've been misguided by nonsense like this.


On 12/11/10 07:09, Sciss wrote:
> beware, your comments are a waste of time. if you want to help in
> this thread, break down your superior knowledge in a way that it is
> shared with others, and explain why something is nonsense in your
> opinion.
>
> Am 11.11.2010 um 20:29 schrieb Tony Morris:
>
> On 11/11/10 22:30, Sciss wrote:
>>>> fp and immutable data structures are celebrated as solving
>>>> all problems, but as you see, they don't, in particular they
>>>> have no clear concept of dynamicity, so things that change
>>>> over time. they don't solve your problem of concurrent access
>>>> here, so you will need to linearize your clients in some way.
>>>> for example, you could manage them with an Actor or use an
>>>> STM... immutable structures and STM play nicely together, as
>>>> when a transaction is aborted you haven't crippled your data
>>>> structure, just the newly created copy (old list plus new
>>>> head element, for instance) isn't stored in the ref, no
>>>> damage is done.
>>>>
>>>> best, -sciss-
> Beware, nonsense lurks there.
>
>>

hello tony,

i think we disagree here about the function and usage of a mailing list.

- if you do not have time because you are too busy, you can avoid the kind of reply you sent
- if you think the mistake(?) is very common, it is even more important to clarify it
- if you have done it many times, why don't you just send a link to an older mailing list
entry? apart from that, redundancy is a good thing.
- in particular i think it is healthy to believe that different people do not occupy a different degree
of truth, because truth ist not linear and absolute, but have different backgrounds
and different viewpoints. a mailing list is a communication means to establish some
kind of common sense (ideally) or consensus through discussion. so to terminate in saying
that something is nonsense or that someone should stop writing "shit" is completely useless.
- my point was that to view a process as a function comes with problems, in particular when
the main concept, temporality, is implicit. there may be better ways to explicate temporality,
although purely functional datastructures can be helpful here by simplifying reasoning
at another instance. and as has been written, you need "impurity" to express the intrusion
of the real world in terms of time-variant elements. the emphatic usage of the terms
"purity" and "state" seems to reveal a transcendental aesthetic that is found in
FP. i find it telling that terms such as "stateless" or "stateful" are used, where the state
is exactly the frozen time, the moment inbetween change, where if you speak in
terms of process, you would typically use the term "change" and "transition" and
inversely the "states" become the holes between transitions.
- as has been written in another reply, the actual problem was really one
of concurrency, and i gave my opinion == experience regarding this point, and i
don't see where your comments add to this.

you know i am generally a modest person, i don't believe i am god or on top of other people, and i thus have no problem in being incorrect in points or being corrected. but i am still not convinced that my text was not making sense.

best, -sciss-

Am 11.11.2010 um 21:19 schrieb Tony Morris:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Alas, if I were to respond to every bit of nonsense on the internet,
> I'd be very busy indeed! Further, your particular misunderstanding is:
>
> a) Extremely common
> b) Extremely difficult (for me anyway) to demonstrate for a general
> audience. I have done so successfully many times, but only with full
> attention being given to the topic one-on-one.
>
> Instead of addressing nonsense of this particular magnitude, I
> request, in the most polite manner possible, the following: Stop
> talking shit. In response, I will go to extraordinary efforts to do
> same, nevertheless acknowledging both of our fallibility.
>
> Sound fair? If not, where do I begin unravelling your fallacious
> comments? It's an honest question -- despite your unawareness of
> falsehood, I simply don't know where to begin.
>
> Do you honestly believe that first sentence? Do you care to put a bit
> more thought into it? I'm don't intend to be a dick, just prevent the
> misguidance of others. Be nice to noobs -- you don't yet know how hard
> it is to help them out after they've been misguided by nonsense like this.
>
>
> On 12/11/10 07:09, Sciss wrote:
> > beware, your comments are a
> waste of time. if you want to help in
>
>
> > this thread, break down your superior knowledge in a way that it
> is
>
>
> > shared with others, and explain why something is nonsense in your
>
>
> > opinion.
>
>
> >
>
>
> > Am 11.11.2010 um 20:29 schrieb Tony Morris:
>
>
> >
>
>
> > On 11/11/10 22:30, Sciss wrote:
>
>
> >>>> fp and immutable data structures are celebrated as
> solving
>
>
> >>>> all problems, but as you see, they don't, in
> particular they
>
>
> >>>> have no clear concept of dynamicity, so things that
> change
>
>
> >>>> over time. they don't solve your problem of
> concurrent access
>
>
> >>>> here, so you will need to linearize your clients in
> some way.
>
>
> >>>> for example, you could manage them with an Actor or
> use an
>
>
> >>>> STM... immutable structures and STM play nicely
> together, as
>
>
> >>>> when a transaction is aborted you haven't crippled
> your data
>
>
> >>>> structure, just the newly created copy (old list
> plus new
>
>
> >>>> head element, for instance) isn't stored in the ref,
> no
>
>
> >>>> damage is done.
>
>
> >>>>
>
>
> >>>> best, -sciss-
>
>
> > Beware, nonsense lurks there.
>
>
> >
>
>
> >>
>
>
> - --
> Tony Morris
> http://tmorris.net/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkzcXd8ACgkQmnpgrYe6r63KyACeMQlOlu3Sr4WJwJni044MVRSP
> 6NkAn2nGR458qzMUA9pmehIKk44u7/Zj
> =qlH5
> -----END PGP SIGNATURE-----
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm happy to help you learn why you are wrong, but I don't think the
list would be. We can just keep it offline.

On the other hand, I have to step in when there are people who have
expressed an interest in learning only to receive a misguided answer.
The list is for learning -- and registering objection to nonsense is
very important for beginners' learning who don't yet have a
comfortable understanding.


On 12/11/10 07:53, Sciss wrote:
> hello tony,
>
> i think we disagree here about the function and usage of a mailing
> list.
>
> - if you do not have time because you are too busy, you can avoid
> the kind of reply you sent - if you think the mistake(?) is very
> common, it is even more important to clarify it - if you have done
> it many times, why don't you just send a link to an older mailing
> list entry? apart from that, redundancy is a good thing. - in
> particular i think it is healthy to believe that different people
> do not occupy a different degree of truth, because truth ist not
> linear and absolute, but have different backgrounds and different
> viewpoints. a mailing list is a communication means to establish
> some kind of common sense (ideally) or consensus through
> discussion. so to terminate in saying that something is nonsense or
> that someone should stop writing "shit" is completely useless. - my
> point was that to view a process as a function comes with problems,
> in particular when the main concept, temporality, is implicit.
> there may be better ways to explicate temporality, although purely
> functional datastructures can be helpful here by simplifying
> reasoning at another instance. and as has been written, you need
> "impurity" to express the intrusion of the real world in terms of
> time-variant elements. the emphatic usage of the terms "purity" and
> "state" seems to reveal a transcendental aesthetic that is found
> in FP. i find it telling that terms such as "stateless" or
> "stateful" are used, where the state is exactly the frozen time,
> the moment inbetween change, where if you speak in terms of
> process, you would typically use the term "change"  and
> "transition" and inversely the "states" become the holes between
> transitions. - as has been written in another reply, the actual
> problem was really one of concurrency, and i gave my opinion ==
> experience regarding this point, and i don't see where your
> comments add to this.
>
> you know i am generally a modest person, i don't believe i am god
> or on top of other people, and i thus have no problem in being
> incorrect in points or being corrected. but i am still not
> convinced that my text was not making sense.
>
> best, -sciss-
>
>
>
> Am 11.11.2010 um 21:19 schrieb Tony Morris:
>
> Alas, if I were to respond to every bit of nonsense on the
> internet, I'd be very busy indeed! Further, your particular
> misunderstanding is:
>
> a) Extremely common b) Extremely difficult (for me anyway) to
> demonstrate for a general audience. I have done so successfully
> many times, but only with full attention being given to the topic
> one-on-one.
>
> Instead of addressing nonsense of this particular magnitude, I
> request, in the most polite manner possible, the following: Stop
> talking shit. In response, I will go to extraordinary efforts to
> do same, nevertheless acknowledging both of our fallibility.
>
> Sound fair? If not, where do I begin unravelling your fallacious
> comments? It's an honest question -- despite your unawareness of
> falsehood, I simply don't know where to begin.
>
> Do you honestly believe that first sentence? Do you care to put a
> bit more thought into it? I'm don't intend to be a dick, just
> prevent the misguidance of others. Be nice to noobs -- you don't
> yet know how hard it is to help them out after they've been
> misguided by nonsense like this.
>
>
> On 12/11/10 07:09, Sciss wrote:
>>>> beware, your comments are a
> waste of time. if you want to help in
>
>
>>>> this thread, break down your superior knowledge in a way that
>>>> it
> is
>
>
>>>> shared with others, and explain why something is nonsense in
>>>> your
>
>
>>>> opinion.
>
>
>>>>
>
>
>>>> Am 11.11.2010 um 20:29 schrieb Tony Morris:
>
>
>>>>
>
>
>>>> On 11/11/10 22:30, Sciss wrote:
>
>
>>>>>>> fp and immutable data structures are celebrated as
> solving
>
>
>>>>>>> all problems, but as you see, they don't, in
> particular they
>
>
>>>>>>> have no clear concept of dynamicity, so things that
> change
>
>
>>>>>>> over time. they don't solve your problem of
> concurrent access
>
>
>>>>>>> here, so you will need to linearize your clients in
> some way.
>
>
>>>>>>> for example, you could manage them with an Actor or
> use an
>
>
>>>>>>> STM... immutable structures and STM play nicely
> together, as
>
>
>>>>>>> when a transaction is aborted you haven't crippled
> your data
>
>
>>>>>>> structure, just the newly created copy (old list
> plus new
>
>
>>>>>>> head element, for instance) isn't stored in the ref,
> no
>
>
>>>>>>> damage is done.
>
>
>>>>>>>
>
>
>>>>>>> best, -sciss-
>
>
>>>> Beware, nonsense lurks there.
>
>
>>>>
>
>
>>>>>
>
>
>>

I find both former posts interesting.

Tony Morris wrote:
>
> I'm happy to help you learn why you are wrong, but I don't think the
> list would be. We can just keep it offline.
>

The question here is: Who is "the list"?

We have here some smart guys, who since a long time contribute to this list.
And OTOH we have newcomers with many questions.
And we have people to be positioned somewhere between this extremes,
e.g. some loyal people who follow the list since a long time
and know you, your position and your comments, and have already learned
some things but aren't already "there".

For these people the previous posts could possibly make some sense and
sound OK, but as you object to them, your reasons may be of worth for them
too,
not only the targeted poster.

Keeping your dialogue offline will presumably result in reincarnating this
thread as
a deja vu at some time in the future, without being able to link back to
this
discussion, as it ended in "nonsense" and more valuable stuff was kept
offline.
(Aren't we already in this position?)
Would be a pity.

Tony Morris wrote:
>
> On the other hand, I have to step in when there are people who have
> expressed an interest in learning only to receive a misguided answer.
> The list is for learning --
>

Absolutely right!
But as I presume that no one here intents to "talk shit", so a request like
"don't talk shit"
is educational nonsense (compare this to the good and bad way to tell
children
what they are doing wrong).

Tony Morris wrote:
>
> and registering objection to nonsense is
> very important for beginners' learning who don't yet have a
> comfortable understanding.

Absolutely right again!
But, see, if it burns it is in no way helpful to put up a sign saying
"Fire!" .
One has to extinguish (well, or run away).

KR
Det

As I really want to get a better understanding of FP and it's concepts I'm constantly searching for good resources to learn. I already worked through loads of articles, blog posts etc on various topics and although some of them are a really good reading it leaves me in the uncomfortable state of feeling unstructured. What I want is a good and decently organized book (or books). So my question to the list is if you have any recommendations regarding good literature about FP.
Thanks,Christoph

Am 11.11.2010 um 22:56 schrieb Tony Morris:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm happy to help you learn why you are wrong, but I don't think the
list would be. We can just keep it offline.

On the other hand, I have to step in when there are people who have
expressed an interest in learning only to receive a misguided answer.
The list is for learning -- and registering objection to nonsense is
very important for beginners' learning who don't yet have a
comfortable understanding.


On 12/11/10 07:53, Sciss wrote:
> hello tony,
>
> i think we disagree here about the function and usage of a mailing
> list.
>
> - if you do not have time because you are too busy, you can avoid
> the kind of reply you sent - if you think the mistake(?) is very
> common, it is even more important to clarify it - if you have done
> it many times, why don't you just send a link to an older mailing
> list entry? apart from that, redundancy is a good thing. - in
> particular i think it is healthy to believe that different people
> do not occupy a different degree of truth, because truth ist not
> linear and absolute, but have different backgrounds and different
> viewpoints. a mailing list is a communication means to establish
> some kind of common sense (ideally) or consensus through
> discussion. so to terminate in saying that something is nonsense or
> that someone should stop writing "shit" is completely useless. - my
> point was that to view a process as a function comes with problems,
> in particular when the main concept, temporality, is implicit.
> there may be better ways to explicate temporality, although purely
> functional datastructures can be helpful here by simplifying
> reasoning at another instance. and as has been written, you need
> "impurity" to express the intrusion of the real world in terms of
> time-variant elements. the emphatic usage of the terms "purity" and
> "state" seems to reveal a transcendental aesthetic that is found
> in FP. i find it telling that terms such as "stateless" or
> "stateful" are used, where the state is exactly the frozen time,
> the moment inbetween change, where if you speak in terms of
> process, you would typically use the term "change"  and
> "transition" and inversely the "states" become the holes between
> transitions. - as has been written in another reply, the actual
> problem was really one of concurrency, and i gave my opinion ==
> experience regarding this point, and i don't see where your
> comments add to this.
>
> you know i am generally a modest person, i don't believe i am god
> or on top of other people, and i thus have no problem in being
> incorrect in points or being corrected. but i am still not
> convinced that my text was not making sense.
>
> best, -sciss-
>
>
>
> Am 11.11.2010 um 21:19 schrieb Tony Morris:
>
> Alas, if I were to respond to every bit of nonsense on the
> internet, I'd be very busy indeed! Further, your particular
> misunderstanding is:
>
> a) Extremely common b) Extremely difficult (for me anyway) to
> demonstrate for a general audience. I have done so successfully
> many times, but only with full attention being given to the topic
> one-on-one.
>
> Instead of addressing nonsense of this particular magnitude, I
> request, in the most polite manner possible, the following: Stop
> talking shit. In response, I will go to extraordinary efforts to
> do same, nevertheless acknowledging both of our fallibility.
>
> Sound fair? If not, where do I begin unravelling your fallacious
> comments? It's an honest question -- despite your unawareness of
> falsehood, I simply don't know where to begin.
>
> Do you honestly believe that first sentence? Do you care to put a
> bit more thought into it? I'm don't intend to be a dick, just
> prevent the misguidance of others. Be nice to noobs -- you don't
> yet know how hard it is to help them out after they've been
> misguided by nonsense like this.
>
>
> On 12/11/10 07:09, Sciss wrote:
>>>> beware, your comments are a
> waste of time. if you want to help in
>
>
>>>> this thread, break down your superior knowledge in a way that
>>>> it
> is
>
>
>>>> shared with others, and explain why something is nonsense in
>>>> your
>
>
>>>> opinion.
>
>
>>>>
>
>
>>>> Am 11.11.2010 um 20:29 schrieb Tony Morris:
>
>
>>>>
>
>
>>>> On 11/11/10 22:30, Sciss wrote:
>
>
>>>>>>> fp and immutable data structures are celebrated as
> solving
>
>
>>>>>>> all problems, but as you see, they don't, in
> particular they
>
>
>>>>>>> have no clear concept of dynamicity, so things that
> change
>
>
>>>>>>> over time. they don't solve your problem of
> concurrent access
>
>
>>>>>>> here, so you will need to linearize your clients in
> some way.
>
>
>>>>>>> for example, you could manage them with an Actor or
> use an
>
>
>>>>>>> STM... immutable structures and STM play nicely
> together, as
>
>
>>>>>>> when a transaction is aborted you haven't crippled
> your data
>
>
>>>>>>> structure, just the newly created copy (old list
> plus new
>
>
>>>>>>> head element, for instance) isn't stored in the ref,
> no
>
>
>>>>>>> damage is done.
>
>
>>>>>>>
>
>
>>>>>>> best, -sciss-
>
>
>>>> Beware, nonsense lurks there.
>
>
>>>>
>
>
>>>>>
>
>
>>

On 11/11/10 21:19, Tony Morris wrote:
> I request, in the most polite manner possible, the following: Stop
> talking shit. In response, I will go to extraordinary efforts to do
> same, nevertheless acknowledging both of our fallibility.

On 11/11/10 21:56, Tony Morris wrote:
> I'm happy to help you learn why you are wrong, but I don't think the
> list would be. We can just keep it offline.

Speaking personally, this thread has been one of the potentially more
interesting ones, and I would be very interested to read your analysis of
Sciss's comments about FP. If you're going to be brash enough to say someone is
"talking shit" on a public list, rightly *or* wrongly, it only seems fair to
back it up with some pretty solid justifications, and/or apologise. On the
other hand, if you can't do either of those, for whatever reason, it is
unavoidably going to reflect badly on yourself.

N

to quote altair from assassin's creed: "speak sense, or not at all".
what sciss said made sense to me. if he is wrong, please tell us why. just telling *that* he is won't make any of us smarter.

-------- Original-Nachricht --------
> Datum: Fri, 12 Nov 2010 07:56:53 +1000
> Von: Tony Morris
> An: Sciss
> CC: tmorris@tmorris.net, scala-user@listes.epfl.ch
> Betreff: Re: [scala-user] functional/immutable programming question

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm happy to help you learn why you are wrong, but I don't think the
> list would be. We can just keep it offline.
>
> On the other hand, I have to step in when there are people who have
> expressed an interest in learning only to receive a misguided answer.
> The list is for learning -- and registering objection to nonsense is
> very important for beginners' learning who don't yet have a
> comfortable understanding.
>
>
> On 12/11/10 07:53, Sciss wrote:
> > hello tony,
> >
> > i think we disagree here about the function and usage of a mailing
> > list.
> >
> > - if you do not have time because you are too busy, you can avoid
> > the kind of reply you sent - if you think the mistake(?) is very
> > common, it is even more important to clarify it - if you have done
> > it many times, why don't you just send a link to an older mailing
> > list entry? apart from that, redundancy is a good thing. - in
> > particular i think it is healthy to believe that different people
> > do not occupy a different degree of truth, because truth ist not
> > linear and absolute, but have different backgrounds and different
> > viewpoints. a mailing list is a communication means to establish
> > some kind of common sense (ideally) or consensus through
> > discussion. so to terminate in saying that something is nonsense or
> > that someone should stop writing "shit" is completely useless. - my
> > point was that to view a process as a function comes with problems,
> > in particular when the main concept, temporality, is implicit.
> > there may be better ways to explicate temporality, although purely
> > functional datastructures can be helpful here by simplifying
> > reasoning at another instance. and as has been written, you need
> > "impurity" to express the intrusion of the real world in terms of
> > time-variant elements. the emphatic usage of the terms "purity" and
> > "state" seems to reveal a transcendental aesthetic that is found
> > in FP. i find it telling that terms such as "stateless" or
> > "stateful" are used, where the state is exactly the frozen time,
> > the moment inbetween change, where if you speak in terms of
> > process, you would typically use the term "change" and
> > "transition" and inversely the "states" become the holes between
> > transitions. - as has been written in another reply, the actual
> > problem was really one of concurrency, and i gave my opinion ==
> > experience regarding this point, and i don't see where your
> > comments add to this.
> >
> > you know i am generally a modest person, i don't believe i am god
> > or on top of other people, and i thus have no problem in being
> > incorrect in points or being corrected. but i am still not
> > convinced that my text was not making sense.
> >
> > best, -sciss-
> >
> >
> >
> > Am 11.11.2010 um 21:19 schrieb Tony Morris:
> >
> > Alas, if I were to respond to every bit of nonsense on the
> > internet, I'd be very busy indeed! Further, your particular
> > misunderstanding is:
> >
> > a) Extremely common b) Extremely difficult (for me anyway) to
> > demonstrate for a general audience. I have done so successfully
> > many times, but only with full attention being given to the topic
> > one-on-one.
> >
> > Instead of addressing nonsense of this particular magnitude, I
> > request, in the most polite manner possible, the following: Stop
> > talking shit. In response, I will go to extraordinary efforts to
> > do same, nevertheless acknowledging both of our fallibility.
> >
> > Sound fair? If not, where do I begin unravelling your fallacious
> > comments? It's an honest question -- despite your unawareness of
> > falsehood, I simply don't know where to begin.
> >
> > Do you honestly believe that first sentence? Do you care to put a
> > bit more thought into it? I'm don't intend to be a dick, just
> > prevent the misguidance of others. Be nice to noobs -- you don't
> > yet know how hard it is to help them out after they've been
> > misguided by nonsense like this.
> >
> >
> > On 12/11/10 07:09, Sciss wrote:
> >>>> beware, your comments are a
> > waste of time. if you want to help in
> >
> >
> >>>> this thread, break down your superior knowledge in a way that
> >>>> it
> > is
> >
> >
> >>>> shared with others, and explain why something is nonsense in
> >>>> your
> >
> >
> >>>> opinion.
> >
> >
> >>>>
> >
> >
> >>>> Am 11.11.2010 um 20:29 schrieb Tony Morris:
> >
> >
> >>>>
> >
> >
> >>>> On 11/11/10 22:30, Sciss wrote:
> >
> >
> >>>>>>> fp and immutable data structures are celebrated as
> > solving
> >
> >
> >>>>>>> all problems, but as you see, they don't, in
> > particular they
> >
> >
> >>>>>>> have no clear concept of dynamicity, so things that
> > change
> >
> >
> >>>>>>> over time. they don't solve your problem of
> > concurrent access
> >
> >
> >>>>>>> here, so you will need to linearize your clients in
> > some way.
> >
> >
> >>>>>>> for example, you could manage them with an Actor or
> > use an
> >
> >
> >>>>>>> STM... immutable structures and STM play nicely
> > together, as
> >
> >
> >>>>>>> when a transaction is aborted you haven't crippled
> > your data
> >
> >
> >>>>>>> structure, just the newly created copy (old list
> > plus new
> >
> >
> >>>>>>> head element, for instance) isn't stored in the ref,
> > no
> >
> >
> >>>>>>> damage is done.
> >
> >
> >>>>>>>
> >
> >
> >>>>>>> best, -sciss-
> >
> >
> >>>> Beware, nonsense lurks there.
> >
> >
> >>>>
> >
> >
> >>>>>
> >
> >
> >>
>
> - --
> Tony Morris
> http://tmorris.net/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkzcZqUACgkQmnpgrYe6r61r+wCfad2C19ipm5wHtoNz14Wr1pQD
> jNgAnAmBQJqxZMNnXG6538LlTohmBiNl
> =GPzV
> -----END PGP SIGNATURE-----
>

On Fri, Nov 12, 2010 at 5:03 AM, Christoph Drießen wrote:
> As I really want to get a better understanding of FP and it's concepts I'm
> constantly searching for good resources to learn. I already worked through
> loads of articles, blog posts etc on various topics and although some of
> them are a really good reading it leaves me in the uncomfortable state of
> feeling unstructured. What I want is a good and decently organized book (or
> books). So my question to the list is if you have any recommendations
> regarding good literature about FP.
> Thanks,
> Christoph

By far the best book I've ever seen on structured design from an FP
point of view is How To Design Programs:

http://www.htdp.org/

+1

At risk of getting flak from both directions...

I think Sciss exaggerated when stating that fp solves "all" problems. Also when saying that functions have no clear concept of dynamicity, when all ballistics etc equations are just that: functions...of time... Which we know now to be discrete... and non-determinism can easily be added... With more functions

STM necessarily implies share memory... Etc

Immutables can "change" by growing into other immutables...and all Denis needs to solve his recurring problem is a "tick tack" ie a stream generating an infinite sequence of ticks, one per second say, and you map over that the next moves on the board...no fancy monadic beasts needed.

Tony is rightfuly pissed at our imprecision. I know that monads are just monoids in the category of endofunctors, but i am necessarily imprecise because I really do feel like an old man fondling elephants and I cant quite find the time to learn the beast in it's totality so I only perceive a few aspects of it...

Well, it was fun writing more imprecise opinions about what others wrote...time for flak!

Thanks,
Razvan

On 2010-11-12, at 5:53 AM, Det2 wrote:

>
> I find both former posts interesting.
>
>
> Tony Morris wrote:
>>
>> I'm happy to help you learn why you are wrong, but I don't think the
>> list would be. We can just keep it offline.
>>
>
> The question here is: Who is "the list"?
>
> We have here some smart guys, who since a long time contribute to this list.
> And OTOH we have newcomers with many questions.
> And we have people to be positioned somewhere between this extremes,
> e.g. some loyal people who follow the list since a long time
> and know you, your position and your comments, and have already learned
> some things but aren't already "there".
>
> For these people the previous posts could possibly make some sense and
> sound OK, but as you object to them, your reasons may be of worth for them
> too,
> not only the targeted poster.
>
> Keeping your dialogue offline will presumably result in reincarnating this
> thread as
> a deja vu at some time in the future, without being able to link back to
> this
> discussion, as it ended in "nonsense" and more valuable stuff was kept
> offline.
> (Aren't we already in this position?)
> Would be a pity.
>
>
> Tony Morris wrote:
>>
>> On the other hand, I have to step in when there are people who have
>> expressed an interest in learning only to receive a misguided answer.
>> The list is for learning --
>>
>
> Absolutely right!
> But as I presume that no one here intents to "talk shit", so a request like
> "don't talk shit"
> is educational nonsense (compare this to the good and bad way to tell
> children
> what they are doing wrong).
>
>
> Tony Morris wrote:
>>
>> and registering objection to nonsense is
>> very important for beginners' learning who don't yet have a
>> comfortable understanding.
>
> Absolutely right again!
> But, see, if it burns it is in no way helpful to put up a sign saying
> "Fire!" .
> One has to extinguish (well, or run away).
>
> KR
> Det

Immutables can "change" by growing into other immutables...and all Denis needs to solve his recurring problem is a "tick tack" ie a stream generating an infinite sequence of ticks, one per second say, and you map over that the next moves on the board...no fancy monadic beasts needed.

-> so simple and elegant. i am happy now.

-------- Original-Nachricht --------
> Datum: Fri, 12 Nov 2010 10:09:25 -0500
> Von: Razvan Cojocaru
> An: Det2
> CC: "scala-user@listes.epfl.ch"
> Betreff: Re: [scala-user] Re: functional/immutable programming question

> +1
>
> At risk of getting flak from both directions...
>
> I think Sciss exaggerated when stating that fp solves "all" problems. Also
> when saying that functions have no clear concept of dynamicity, when all
> ballistics etc equations are just that: functions...of time... Which we know
> now to be discrete... and non-determinism can easily be added... With more
> functions
>
> STM necessarily implies share memory... Etc
>
> Immutables can "change" by growing into other immutables...and all Denis
> needs to solve his recurring problem is a "tick tack" ie a stream generating
> an infinite sequence of ticks, one per second say, and you map over that
> the next moves on the board...no fancy monadic beasts needed.
>
> Tony is rightfuly pissed at our imprecision. I know that monads are just
> monoids in the category of endofunctors, but i am necessarily imprecise
> because I really do feel like an old man fondling elephants and I cant quite
> find the time to learn the beast in it's totality so I only perceive a few
> aspects of it...
>
> Well, it was fun writing more imprecise opinions about what others
> wrote...time for flak!
>
> Thanks,
> Razvan
>
> On 2010-11-12, at 5:53 AM, Det2 wrote:
>
> >
> > I find both former posts interesting.
> >
> >
> > Tony Morris wrote:
> >>
> >> I'm happy to help you learn why you are wrong, but I don't think the
> >> list would be. We can just keep it offline.
> >>
> >
> > The question here is: Who is "the list"?
> >
> > We have here some smart guys, who since a long time contribute to this
> list.
> > And OTOH we have newcomers with many questions.
> > And we have people to be positioned somewhere between this extremes,
> > e.g. some loyal people who follow the list since a long time
> > and know you, your position and your comments, and have already learned
> > some things but aren't already "there".
> >
> > For these people the previous posts could possibly make some sense and
> > sound OK, but as you object to them, your reasons may be of worth for
> them
> > too,
> > not only the targeted poster.
> >
> > Keeping your dialogue offline will presumably result in reincarnating
> this
> > thread as
> > a deja vu at some time in the future, without being able to link back to
> > this
> > discussion, as it ended in "nonsense" and more valuable stuff was kept
> > offline.
> > (Aren't we already in this position?)
> > Would be a pity.
> >
> >
> > Tony Morris wrote:
> >>
> >> On the other hand, I have to step in when there are people who have
> >> expressed an interest in learning only to receive a misguided answer.
> >> The list is for learning --
> >>
> >
> > Absolutely right!
> > But as I presume that no one here intents to "talk shit", so a request
> like
> > "don't talk shit"
> > is educational nonsense (compare this to the good and bad way to tell
> > children
> > what they are doing wrong).
> >
> >
> > Tony Morris wrote:
> >>
> >> and registering objection to nonsense is
> >> very important for beginners' learning who don't yet have a
> >> comfortable understanding.
> >
> > Absolutely right again!
> > But, see, if it burns it is in no way helpful to put up a sign saying
> > "Fire!" .
> > One has to extinguish (well, or run away).
> >
> > KR
> > Det
> > --
> > View this message in context:
> http://scala-programming-language.1934581.n4.nabble.com/functional-immut...
> > Sent from the Scala - User mailing list archive at Nabble.com.
>

All,

> and all Denis needs to solve his recurring problem is a "tick tack" ie a stream generating an infinite sequence of ticks

at the risk of also being accused of not really contributing to this discussion :-)

in 2005 John Hughes wrote a paper on how to use arrows to deal with
situations like this (and also to deal with feedback (hardware circuits design))

http://www.cse.chalmers.se/~rjmh/afp-arrows.pdf

so, yes, imho finding the right abstraction to attack problems does matter
[ monads are not abstract enough (not every arrow is a function A => M[B]) where M is a monad ]


Luc


On Fri, Nov 12, 2010 at 4:18 PM, Dennis Haupt <h-star@gmx.de> wrote:

Immutables can "change" by growing into other immutables...and all Denis needs to solve his recurring problem is a "tick tack" ie a stream generating an infinite sequence of ticks, one per second say, and you map over that the next moves on the board...no fancy monadic beasts needed.

-> so simple and elegant. i am happy now.

-------- Original-Nachricht --------
> Datum: Fri, 12 Nov 2010 10:09:25 -0500
> Von: Razvan Cojocaru <pub@razie.com>
> An: Det2 <Dirk.Detering@bitmarck.de>
> CC: "scala-user@listes.epfl.ch" <scala-user@listes.epfl.ch>
> Betreff: Re: [scala-user] Re: functional/immutable programming question

> +1
>
> At risk of getting flak from both directions...
>
> I think Sciss exaggerated when stating that fp solves "all" problems. Also
> when saying that functions have no clear concept of dynamicity, when all
> ballistics etc equations are just that: functions...of time... Which we know
> now to be discrete... and non-determinism can easily be added... With more
> functions
>
> STM necessarily implies share memory... Etc
>
> Immutables can "change" by growing into other immutables...and all Denis
> needs to solve his recurring problem is a "tick tack" ie a stream generating
> an infinite sequence of ticks, one per second say, and you map over that
> the next moves on the board...no fancy monadic beasts needed.
>
> Tony is rightfuly pissed at our imprecision. I know that monads are just
> monoids in the category of endofunctors, but i am necessarily imprecise
> because I really do feel like an old man fondling elephants and I cant quite
> find the time to learn the beast in it's totality so I only perceive a few
> aspects of it...
>
> Well, it was fun writing more imprecise opinions about what others
> wrote...time for flak!
>
> Thanks,
> Razvan
>
> On 2010-11-12, at 5:53 AM, Det2 <Dirk.Detering@bitmarck.de> wrote:
>
> >
> > I find both former posts interesting.
> >
> >
> > Tony Morris wrote:
> >>
> >> I'm happy to help you learn why you are wrong, but I don't think the
> >> list would be. We can just keep it offline.
> >>
> >
> > The question here is: Who is "the list"?
> >
> > We have here some smart guys, who since a long time contribute to this
> list.
> > And OTOH we have newcomers with many questions.
> > And we have people to be positioned somewhere between this extremes,
> > e.g. some loyal people who follow the list since a long time
> > and know you, your position and your comments, and have already learned
> > some things but aren't already "there".
> >
> > For these people the previous posts could possibly make some sense and
> > sound OK, but as you object to them, your reasons may be of worth for
> them
> > too,
> > not only the targeted poster.
> >
> > Keeping your dialogue offline will presumably result in reincarnating
> this
> > thread as
> > a deja vu at some time in the future, without being able to link back to
> > this
> > discussion, as it ended in "nonsense" and more valuable stuff was kept
> > offline.
> > (Aren't we already in this position?)
> > Would be a pity.
> >
> >
> > Tony Morris wrote:
> >>
> >> On the other hand, I have to step in when there are people who have
> >> expressed an interest in learning only to receive a misguided answer.
> >> The list is for learning --
> >>
> >
> > Absolutely right!
> > But as I presume that no one here intents to "talk shit", so a request
> like
> > "don't talk shit"
> > is educational nonsense (compare this to the good and bad way to tell
> > children
> > what they are doing wrong).
> >
> >
> > Tony Morris wrote:
> >>
> >> and registering objection to nonsense is
> >> very important for beginners' learning who don't yet have a
> >> comfortable understanding.
> >
> > Absolutely right again!
> > But, see, if it burns it is in no way helpful to put up a sign saying
> > "Fire!" .
> > One has to extinguish (well, or run away).
> >
> > KR
> > Det
> > --
> > View this message in context:
> http://scala-programming-language.1934581.n4.nabble.com/functional-immutable-programming-question-tp3037504p3039412.html
> > Sent from the Scala - User mailing list archive at Nabble.com.
>

--
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

--
   __~O
  -\ <,
(*)/ (*)

reality goes far beyond imagination

And here, guys, I get my personal Groundhog Day:

After all talkings about the usability of Scala and its applicability in
all-days developer business and typical programmer's projects, we once again
came back to the original Scala-User thread pattern.

An "ordinary" OO programmer (sorry HamsterOfDeath) heard all this rumours
about this FP stuff and asks in the Scala-User list the unavoidable
question:

>in pure functional programming, there are no side effects. this means, the
only "effect" a method has is
>its returned value, right? it doesn't hold a mutable state.
>
>if so, how do i implement something that HAS to hold a state? what if let's
say 10 clients try to add
>elements to the same list instance? there has to be a managing class that
holds the list, right?

Some time later someone comes up with a "declaration" only involving type
signatures, without any usage or implementation examples.

And not after long the thread mutates to a discussion with phrases like
this:

> [...] that monads are just monoids in the category of endofunctors [...]

enventually followed by someone coming up with an academic paper involving
TheOtherFPLanguage: Haskell.

Is this a variant of Godwin's law?

Sorry boys, but we questioners try to learn Scala, not Haskell, and get
these statements about this immutability and the blessings of FP unveiled,
to gain something for our daily job.

So the basic question is: How can we (no: you, as I'm part of the
questioner side) transport the answers to these questions in an
understandable way to the mass, for the benefit of the (future?) ordinary
JVM business developer and for Scala as a language?
One typical answer to this question would be "show'em a sample".

I feel the need for an "Introduction into Functional Programming - FP
concepts explained in Scala" book, that is close enough to practical
problems of professional developers.
(NB: The german book "Grundkurs Funktionale Programmierung mit Scala" is a
nice start, but contains only a third of the necessary space to dive deep
enough into this matter, so it is really a very basic course).

@HamsterOfDeath: My current state is: I put the question about pure FP
aside and focussed on what Scala is: A hybrid FP / OO language. To be
productive with Scala, the best is to use it that way and apply the concepts
that best fit to solve a particular problem, and that involves side effects
in some dedicated parts of your program.

KR
Det

It's hard to get deep into FP *without* terms like monad, monoid, endofunctor, catamorphism, etc. being involved.
Then again, it's even harder to find any reference to these terms that doesn't use Haskell as the language-de-jour for explaining them.  I've long searched for a good *approachable* programmer-oriented introduction to category theory that also doesn't rapidly fall back on either Haskell (or on higher-mathematics, but those generally fail the "approachability" test).  So far, this search has been in vain.
If you're serious about this material, then the only advice in town is still, essentially, "first learn Haskell..." - and that's just plain frustrating.  Not that I would ever discourage anyone from learning the language, it's one that every programmer really ought to know, but that's sometimes just not a realistic option when faced with commercial time pressure.


On 16 November 2010 09:30, Det2 <Dirk.Detering@bitmarck.de> wrote:

And here, guys, I get my personal Groundhog Day:

After all talkings about the usability of Scala and its applicability in
all-days developer business and typical programmer's projects, we once again
came back to the original Scala-User thread pattern.

An "ordinary" OO programmer (sorry HamsterOfDeath) heard all this rumours
about this FP stuff and asks in the Scala-User list the unavoidable
question:

>in pure functional programming, there are no side effects. this means, the
only "effect" a method has is
>its returned value, right? it doesn't hold a mutable state.
>
>if so, how do i implement something that HAS to hold a state? what if let's
say 10 clients try to add
>elements to the same list instance? there has to be a managing class that
holds the list, right?

Some time later someone comes up with a "declaration" only involving type
signatures, without any usage  or implementation examples.

And not after long the thread mutates to a discussion with phrases like
this:

> [...] that monads are just monoids in the category of endofunctors [...]

enventually followed by someone coming up with an academic paper involving
TheOtherFPLanguage: Haskell.

Is this a variant of Godwin's law?

Sorry boys, but we questioners try to learn Scala, not Haskell, and get
these statements about this immutability and the blessings of FP unveiled,
to gain something for our daily job.

So the basic question is:  How can we (no: you, as I'm part of the
questioner side) transport the answers to these questions in an
understandable way to the mass, for the benefit of the (future?) ordinary
JVM business developer and for Scala as a language?
One typical answer to this question would be "show'em a sample".

I feel the need for an "Introduction into Functional Programming - FP
concepts explained in Scala" book, that is close enough to practical
problems of professional developers.
(NB: The german book "Grundkurs Funktionale Programmierung mit Scala" is a
nice start, but contains only a third of the necessary space to dive deep
enough into this matter, so it is really a very basic course).


@HamsterOfDeath:  My current state is: I put the question about pure FP
aside and focussed on what Scala is: A hybrid FP / OO language.  To be
productive with Scala, the best is to use it that way and apply the concepts
that best fit to solve a particular problem, and that involves side effects
in some dedicated parts of your program.

KR
Det
--
View this message in context: http://scala-programming-language.1934581.n4.nabble.com/functional-immutable-programming-question-tp3037504p3044476.html
Sent from the Scala - User mailing list archive at Nabble.com.

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

Hello Kevin,

I recall a tutorial on category theory for software engineers that was
given by steve easterbrook at U of Toronto.

http://www.cs.toronto.edu/~sme/presentations/cat101.pdf

Not sure however or accessible this is.

He has also done some work further upstream (specification evolution) in
conjunction with category theory.

To what extent is category theory in your mind necessary to become a
professional Scala programmer? I.e. to create software that is
performant but also understandable, maintainable, changeable and
evolvable?

thanks,

Daniel

On Tue, 2010-11-16 at 09:46 +0000, Kevin Wright wrote:
> It's hard to get deep into FP *without* terms like monad, monoid,
> endofunctor, catamorphism, etc. being involved.
>
>
> Then again, it's even harder to find any reference to these terms that
> doesn't use Haskell as the language-de-jour for explaining them. I've
> long searched for a good *approachable* programmer-oriented
> introduction to category theory that also doesn't rapidly fall back on
> either Haskell (or on higher-mathematics, but those generally fail the
> "approachability" test). So far, this search has been in vain.
>
>
> If you're serious about this material, then the only advice in town is
> still, essentially, "first learn Haskell..." - and that's just plain
> frustrating. Not that I would ever discourage anyone from learning
> the language, it's one that every programmer really ought to know, but
> that's sometimes just not a realistic option when faced with
> commercial time pressure.
>
>
>
> On 16 November 2010 09:30, Det2 wrote:
>
> And here, guys, I get my personal Groundhog Day:
>
> After all talkings about the usability of Scala and its
> applicability in
> all-days developer business and typical programmer's projects,
> we once again
> came back to the original Scala-User thread pattern.
>
> An "ordinary" OO programmer (sorry HamsterOfDeath) heard all
> this rumours
> about this FP stuff and asks in the Scala-User list the
> unavoidable
> question:
>
> >in pure functional programming, there are no side effects.
> this means, the
> only "effect" a method has is
> >its returned value, right? it doesn't hold a mutable state.
> >
> >if so, how do i implement something that HAS to hold a state?
> what if let's
> say 10 clients try to add
> >elements to the same list instance? there has to be a
> managing class that
> holds the list, right?
>
>
> Some time later someone comes up with a "declaration" only
> involving type
> signatures, without any usage or implementation examples.
>
> And not after long the thread mutates to a discussion with
> phrases like
> this:
>
> > [...] that monads are just monoids in the category of
> endofunctors [...]
>
> enventually followed by someone coming up with an academic
> paper involving
> TheOtherFPLanguage: Haskell.
>
> Is this a variant of Godwin's law?
>
> Sorry boys, but we questioners try to learn Scala, not
> Haskell, and get
> these statements about this immutability and the blessings of
> FP unveiled,
> to gain something for our daily job.
>
> So the basic question is: How can we (no: you, as I'm part of
> the
> questioner side) transport the answers to these questions in
> an
> understandable way to the mass, for the benefit of the
> (future?) ordinary
> JVM business developer and for Scala as a language?
> One typical answer to this question would be "show'em a
> sample".
>
> I feel the need for an "Introduction into Functional
> Programming - FP
> concepts explained in Scala" book, that is close enough to
> practical
> problems of professional developers.
> (NB: The german book "Grundkurs Funktionale Programmierung mit
> Scala" is a
> nice start, but contains only a third of the necessary space
> to dive deep
> enough into this matter, so it is really a very basic course).
>
>
> @HamsterOfDeath: My current state is: I put the question
> about pure FP
> aside and focussed on what Scala is: A hybrid FP / OO
> language. To be
> productive with Scala, the best is to use it that way and
> apply the concepts
> that best fit to solve a particular problem, and that involves
> side effects
> in some dedicated parts of your program.
>
> KR
> Det
> --
> View this message in context:
> http://scala-programming-language.1934581.n4.nabble.com/functional-immut...
>
> Sent from the Scala - User mailing list archive at Nabble.com.
>
>
>
>

Det2 wrote:
> enventually followed by someone coming up with an academic paper involving
> TheOtherFPLanguage: Haskell.

I guess Haskell is brought up not because it is "the other FP language"
(there are (OCA)ML / F#, Lisp / Scheme, Erlang, too, mind you..) but
because it is the probably best known pure[1] language and the
discussion at that point was about purity.

If you want to avoid side-effects in Scala, in my understanding (I am
just a learner, too), one has to do it by convention (which seems
meaningless when you use Java libraries). There is no way to guarantee
it (in Scala), although as far as I am aware, there is research on this
topic going on currently. So what I am in fact doing is learning the
pure FP way by learning Haskell[2][3] (and some category theory [4])
thoroughly and then see how much of that I can apply to Scala and the
JVM. This seems like a lot of work lies in front of me.

If anybody knows a shortcut, I'd be delighted to hear about it. I'd
also be delighted about any book recommendations.

Kind regards
Andreas

[1]
http://haskell.org/haskellwiki/Comparison_of_functional_programming_lang...
[2] Real world Haskell (ISBN 978-0596514983)
[3] Pearls of functional algorithm design (ISBN 978-0521513388)
[4] Conceptual Mathematics: A First Introduction to Categories (ISBN
978-0521719162)

P.S.
I'd prefer if the discussion about these topics were less heated and
more open-minded and with more actual references than bold claims.

Here is my opinion on this,

you do not have to be a die-hard fp programmer to learn about the
benefits of side effect free programming

there is nothing wrong with carefully writing libraries that, internally,
have side effects, but, externally, offer a side effect free contract
(for example: the collections library)

in Martin's "Scala By Example" paper he shows a type inferencer algorithm
that makes use of a var that is used for generating a new
type variable name

object typeInfer {
 private var n: Int = 0
 def newTyvar(): Type = { n += 1; Tyvar("a" + n) }
 
imo, this is a perfect example of a pragmatic choice
(he could have used the state monad instead)

(big) benefit: simplicity
(small) drawback: the side effect is not known to the type system,
but, hey, the variable n is private anyway, and the only thing one
can do is invoke newTyvar()


Luc

--
   __~O
  -\ <,
(*)/ (*)

reality goes far beyond imagination

Luc Duponcheel wrote:
> you do not have to be a die-hard fp programmer to learn about the
> benefits of side effect free programming

Absolutely. That even works in Java.

> there is nothing wrong with carefully writing libraries that,
> internally,
> have side effects, but, externally, offer a side effect free
> contract
> (for example: the collections library)

That depends a lot on the side-effect, I'd say. If you can completely
hide it, then it may work out. But doing so may be harder than it looks.

(snip)
> object typeInfer {
> private var n: Int = 0
> def newTyvar(): Type = { n += 1; Tyvar("a" + n) }
>
> imo, this is a perfect example of a pragmatic choice
> (he could have used the state monad instead)
>
> (big) benefit: simplicity
> (small) drawback: the side effect is not known to the type system,
> but, hey, the variable n is private anyway, and the only thing one
> can do is invoke newTyvar()

This example isn't thread-safe, is it? So the side effect escapes even
though the visibility modifier tries to hide it: the client needs to
synchronize externally or restrict itself to one thread. If I recall
correctly Stream cons (or was it List cons?) in the library had this
kind of hidden thread vulnerability.

Also, the method is not referentially transparent: it returns two
different values for two identical invocations. In other words, there is
an observable side effect.

All I wanted to say is: it may be much trickier than it seems at first
glance.

Thanks for sharing your opinion.

Kind regards
Andreas

I guess what got some of us off track is that the original post asked
about "pure functional programming"...

> This example isn't thread-safe, is it? So the side effect escapes even
> though the visibility modifier tries to hide it: the client needs to
> synchronize externally or restrict itself to one thread. If I recall
> correctly Stream cons (or was it List cons?) in the library had this
> kind of hidden thread vulnerability.

indeed, but, I guess that, in this case, writing a correct algorithm
for single threaded usage was already challenging enough :-)

> Also, the method is not referentially transparent: it returns two
> different values for two identical invocations. In other words, there is
> an observable side effect.

correct, but even that method could be encapsulated: after all
the only thing that the type inferencer has to expose is it's
infer method (which is referentially transparent)

> All I wanted to say is: it may be much trickier than it seems at first
> glance.

I agree

> Thanks for sharing your opinion

thx


--
   __~O
  -\ <,
(*)/ (*)

reality goes far beyond imagination

Without yet really knowing Scala much (i just started to learn about the
language), perhaps it's worth defining three classes of programs a) pure
functional that are guaranteed to have no side-effects and b) mixed
programs, where side-effects are possible. And b) could be further
classified into b.1) programs with well localized side effects and b.2)
hybrid programs.

Perhaps this would imply defining different subsets of Scala and
libraries use.

Any program of class a) would be guaranteed to run in a parallel
processing environment, while for b.1) a guarantee is contingent on
programmer properly dealing with the localized side effects. a program
of category b.2) has no guarantees and should be run in a non
parallelized environment.

does this make sense?

thanks,

Daniel

On Tue, 2010-11-16 at 12:18 +0100, Luc Duponcheel wrote:
> > This example isn't thread-safe, is it? So the side effect escapes
> even
> > though the visibility modifier tries to hide it: the client needs to
> > synchronize externally or restrict itself to one thread. If I recall
> > correctly Stream cons (or was it List cons?) in the library had this
> > kind of hidden thread vulnerability.
>
> indeed, but, I guess that, in this case, writing a correct algorithm
> for single threaded usage was already challenging enough :-)
>
> > Also, the method is not referentially transparent: it returns two
> > different values for two identical invocations. In other words,
> there is
> > an observable side effect.
>
> correct, but even that method could be encapsulated: after all
> the only thing that the type inferencer has to expose is it's
> infer method (which is referentially transparent)
>
> > All I wanted to say is: it may be much trickier than it seems at
> first
> > glance.
>
> I agree
>
> > Thanks for sharing your opinion
>
> thx
>
>

As immutability is a must-have if you need referential integrity, it's core to FP design; but it also works very nicely alongside object-oriented designs as well (just consider Java's enum types).
So asking about immutability isn't necessarily a question about FP.  FP theory goes a *long* way beyond that starting point...

On 16 November 2010 11:07, Robert Wills <wrwills@gmail.com> wrote:

I guess what got some of us off track is that the original post asked
about "pure functional programming"...

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

Daniel Gross wrote:
> Without yet really knowing Scala much (i just started to learn about the
> language), perhaps it's worth defining three classes of programs a) pure
> functional that are guaranteed to have no side-effects and b) mixed
> programs, where side-effects are possible. And b) could be further
> classified into b.1) programs with well localized side effects and b.2)
> hybrid programs.

As far as I am concerned, all Scala programs fall under b as there is
(currently) no way
to guarantee purity in Scala (as far as I am aware).

The key point here (for me) is in the "guarantee". The absence of
unintended side effects (sounds like a bug to me) cannot be shown by
testing. Testing can only show the presence of bugs. So we need
something better. "Because the programmer says it is." does not qualify
either. So it comes down to the compiler guaranteeing purity.

> Perhaps this would imply defining different subsets of Scala and
> libraries use.
>
> Any program of class a) would be guaranteed to run in a parallel
> processing environment, while for b.1) a guarantee is contingent on
> programmer properly dealing with the localized side effects. a program
> of category b.2) has no guarantees and should be run in a non
> parallelized environment.

Side effects are not just about threads. Imagine a library that
internally logs stuff to the disk. Your application uses this library
while it writes its own data to the disk, knowing nothing about that
side effect. The log file fills the disk -> ouch
Of course this example may be rather constructed but you get the idea.
:)

Kind regards
Andreas

Hello Andreas,

I guess what you are writing is a bit surprising to me. I thought that
one of the key selling points for a functional language like Scala, is
the easy with which program execution can be distributed across
cores/processors.

It should be possible to clearly establish that a program, or at least,
a well designated portion of a program, can be parallelized without any
problems.

thanks,

Daniel

On Tue, 2010-11-16 at 12:47 +0100, Andreas Flierl wrote:
> Daniel Gross wrote:
> > Without yet really knowing Scala much (i just started to learn about the
> > language), perhaps it's worth defining three classes of programs a) pure
> > functional that are guaranteed to have no side-effects and b) mixed
> > programs, where side-effects are possible. And b) could be further
> > classified into b.1) programs with well localized side effects and b.2)
> > hybrid programs.
>
> As far as I am concerned, all Scala programs fall under b as there is
> (currently) no way
> to guarantee purity in Scala (as far as I am aware).
>
> The key point here (for me) is in the "guarantee". The absence of
> unintended side effects (sounds like a bug to me) cannot be shown by
> testing. Testing can only show the presence of bugs. So we need
> something better. "Because the programmer says it is." does not qualify
> either. So it comes down to the compiler guaranteeing purity.
>
> > Perhaps this would imply defining different subsets of Scala and
> > libraries use.
> >
> > Any program of class a) would be guaranteed to run in a parallel
> > processing environment, while for b.1) a guarantee is contingent on
> > programmer properly dealing with the localized side effects. a program
> > of category b.2) has no guarantees and should be run in a non
> > parallelized environment.
>
> Side effects are not just about threads. Imagine a library that
> internally logs stuff to the disk. Your application uses this library
> while it writes its own data to the disk, knowing nothing about that
> side effect. The log file fills the disk -> ouch
> Of course this example may be rather constructed but you get the idea.
> :)
>
> Kind regards
> Andreas

Wrong way round... you should define a part that uses side-effects, attempt to minimise/localise that, then parallelize the rest freely :)


On 16 November 2010 12:25, Daniel Gross <daniel.gross@utoronto.ca> wrote:

Hello Andreas,

I guess what you are writing is a bit surprising to me. I thought that
one of the key selling points for a functional language like Scala, is
the easy with which program execution can be distributed across
cores/processors.

It should be possible to clearly establish that a program, or at least,
a well designated portion of a program, can be parallelized without any
problems.

thanks,

Daniel

On Tue, 2010-11-16 at 12:47 +0100, Andreas Flierl wrote:
> Daniel Gross <daniel.gross@utoronto.ca> wrote:
> > Without yet really knowing Scala much (i just started to learn about the
> > language), perhaps it's worth defining three classes of programs a) pure
> > functional that are guaranteed to have no side-effects and b) mixed
> > programs, where side-effects are possible. And  b) could be further
> > classified into b.1) programs with well localized side effects and b.2)
> > hybrid programs.
>
> As far as I am concerned, all Scala programs fall under b as there is
> (currently) no way
> to guarantee purity in Scala (as far as I am aware).
>
> The key point here (for me) is in the "guarantee". The absence of
> unintended side effects (sounds like a bug to me) cannot be shown by
> testing. Testing can only show the presence of bugs. So we need
> something better. "Because the programmer says it is." does not qualify
> either. So it comes down to the compiler guaranteeing purity.
>
> > Perhaps this would imply defining different subsets of Scala and
> > libraries use.
> >
> > Any program of class a) would be guaranteed to run in a parallel
> > processing environment, while for b.1) a guarantee is contingent on
> > programmer properly dealing with the localized side effects. a program
> > of category b.2) has no guarantees and should be run in a non
> > parallelized environment.
>
> Side effects are not just about threads. Imagine a library that
> internally logs stuff to the disk. Your application uses this library
> while it writes its own data to the disk, knowing nothing about that
> side effect. The log file fills the disk -> ouch
> Of course this example may be rather constructed but you get the idea.
> :)
>
> Kind regards
> Andreas

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

Daniel Gross wrote:

> I guess what you are writing is a bit surprising to me. I thought that
> one of the key selling points for a functional language like Scala, is
> the easy with which program execution can be distributed across
> cores/processors.

I would still say it is far easier to do so in Scala than in Java. See
below for my attempt of reasoning about it.

> It should be possible to clearly establish that a program, or at least,
> a well designated portion of a program, can be parallelized without any
> problems.

Again, the key point is in the guarantee, or "clearly establish"ing.
For example, it is possible to write programs without any runtime type
errors in a dynamically typed language. Many find it a lot easier in a
statically typed language, where the compiler verifies your types.

It may be a bit like that in the case of parallelism. The (Scala)
compiler cannot (or better: currently does not) guarantee thread-safety.
Therefore you have to rely on testing and/or the programmer telling you:
this library or part of the program is thread-safe. I personally find
this a dire situation. So the only way to get to the point where you
could say that safe parallelization of a program is a "clearly
establish"ed proptery of that program would be to have it used and
tested to the point where you at least gain a good level of confidence
about that property. That's no guarantee, mind you, but it may work out.

Back to the point why I still think Scala makes it quite a bit easier
to write correct parallel programs.

a) The Scala language allows[1] to create the libraries with the
necessary abstractions to handle all (or most) of the gory threading
details for you while keeping the resulting code readable and
maintainable. Over time, these libraries will mature enough that you can
take it for "clearly established" that they can be safely used to
parallelize your program.

b) Functional programming constructs promote immutability and allow for
composing algorithms from other algorithms. Since these constructs are
(more or less) battle-tested, you can (more or less) take it as "clearly
established" that if you compose a safe function with a safe function, a
safe function will result.

c) The problem remains when is your own function/method/whatever safe
for parallelization. Currently the only way (in Scala) I am aware of is
by testing, testing, more testing and probably reasoning about the code,
preferably with several programmers looking at it. I find this
sub-optimal. There is no guarantee.

From my experience, a) and b) are what makes correct parallelization in
Scala easier than in many other languages.

With all of this, please keep in mind that I am neither an expert in
Scala nor in functional programming. This is all my observation and
(maybe faulty) reasoning. I'd hope some more proficient people chime in
here.

Kind regards
Andreas

[1] I am thinking of resulting brevity and expressivity through
first-class functions, anonymous functions, partial functions, type
inference, pattern matching, views etc. etc. I think this is a big thing
and often understimated.

Now that I am reading it again, I also noticed one more thing.

Daniel Gross wrote:
> I guess what you are writing is a bit surprising to me. I thought that
> one of the key selling points for a functional language like Scala, is
> the easy with which program execution can be distributed across
> cores/processors.

Please let me question the phrase "a functional language like Scala".
It raises three questions in my head:

1) Just what exactly IS functional? I have read diverging definitions.
2) How functional is Scala? They don't call it object-functional or
postfunctional for no reason, I'd guess.
3) How many other languages are "like Scala"? The functional languages
I know are so different that I personally would have a hard time
reasoning about all of them at once (how functional are they all? what's
their type system like? are they pure?). Then again, I am no functional
programming expert.

Kind regards
Andreas

So my attempt at explaining how monads help encapsulate side-effects failed miserably... The part with "monoids in the category of endofunctors" was a joke as was fondling elephants. You should read James Iry's blog, might shed more kith into monads and why they're useful.

Cheers,
Razvan

On 2010-11-16, at 6:18 AM, Luc Duponcheel wrote:

> > This example isn't thread-safe, is it? So the side effect escapes even
> > though the visibility modifier tries to hide it: the client needs to
> > synchronize externally or restrict itself to one thread. If I recall
> > correctly Stream cons (or was it List cons?) in the library had this
> > kind of hidden thread vulnerability.
>
> indeed, but, I guess that, in this case, writing a correct algorithm
> for single threaded usage was already challenging enough :-)
>
> > Also, the method is not referentially transparent: it returns two
> > different values for two identical invocations. In other words, there is
> > an observable side effect.
>
> correct, but even that method could be encapsulated: after all
> the only thing that the type inferencer has to expose is it's
> infer method (which is referentially transparent)
>
> > All I wanted to say is: it may be much trickier than it seems at first
> > glance.
>
> I agree
>
> > Thanks for sharing your opinion
>
> thx
>
>

Kevin (and others (?)),

> Wrong way round... you should define a part that uses side-effects ...

a question (also with the requirements of Andreas (concurrency) in mind
(in particular I was thinking of concurrency combined with state))

for those parts it is best to use actors for dealing with concurrency and state, right?
or is such an approach sometimes somewhat of an overkill?

Luc



On Tue, Nov 16, 2010 at 1:31 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

Wrong way round... you should define a part that uses side-effects, attempt to minimise/localise that, then parallelize the rest freely :)


On 16 November 2010 12:25, Daniel Gross <daniel.gross@utoronto.ca> wrote:

Hello Andreas,

I guess what you are writing is a bit surprising to me. I thought that
one of the key selling points for a functional language like Scala, is
the easy with which program execution can be distributed across
cores/processors.

It should be possible to clearly establish that a program, or at least,
a well designated portion of a program, can be parallelized without any
problems.

thanks,

Daniel

On Tue, 2010-11-16 at 12:47 +0100, Andreas Flierl wrote:
> Daniel Gross <daniel.gross@utoronto.ca> wrote:
> > Without yet really knowing Scala much (i just started to learn about the
> > language), perhaps it's worth defining three classes of programs a) pure
> > functional that are guaranteed to have no side-effects and b) mixed
> > programs, where side-effects are possible. And  b) could be further
> > classified into b.1) programs with well localized side effects and b.2)
> > hybrid programs.
>
> As far as I am concerned, all Scala programs fall under b as there is
> (currently) no way
> to guarantee purity in Scala (as far as I am aware).
>
> The key point here (for me) is in the "guarantee". The absence of
> unintended side effects (sounds like a bug to me) cannot be shown by
> testing. Testing can only show the presence of bugs. So we need
> something better. "Because the programmer says it is." does not qualify
> either. So it comes down to the compiler guaranteeing purity.
>
> > Perhaps this would imply defining different subsets of Scala and
> > libraries use.
> >
> > Any program of class a) would be guaranteed to run in a parallel
> > processing environment, while for b.1) a guarantee is contingent on
> > programmer properly dealing with the localized side effects. a program
> > of category b.2) has no guarantees and should be run in a non
> > parallelized environment.
>
> Side effects are not just about threads. Imagine a library that
> internally logs stuff to the disk. Your application uses this library
> while it writes its own data to the disk, knowing nothing about that
> side effect. The log file fills the disk -> ouch
> Of course this example may be rather constructed but you get the idea.
> :)
>
> Kind regards
> Andreas

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

--
   __~O
  -\ <,
(*)/ (*)

reality goes far beyond imagination

Gents, again wikipedia to the rescue In computer science, functional programming is a programming paradigm that treatscomputation as the evaluation of mathematical functions and avoids state and mutable data. It emphasizes the application of functions, in contrast to the imperative programming style, which emphasizes changes in state.[1] Functional programming has its roots in lambda calculus, a formal system developed in the 1930s to investigate function definition, function application, and recursion. Many functional programming languages can be viewed as elaborations on the lambda calculus

Thanks,Razvan
On 2010-11-16, at 8:32 AM, Andreas Flierl <andreas@flierl.eu> wrote:

Now that I am reading it again, I also noticed one more thing.

Daniel Gross <daniel.gross@utoronto.ca> wrote:

I guess what you are writing is a bit surprising to me. I thought that

one of the key selling points for a functional language like Scala, is

the easy with which program execution can be distributed across

cores/processors.

Please let me question the phrase "a functional language like Scala".
It raises three questions in my head:

1) Just what exactly IS functional? I have read diverging definitions.
2) How functional is Scala? They don't call it object-functional or
postfunctional for no reason, I'd guess.
3) How many other languages are "like Scala"? The functional languages
I know are so different that I personally would have a hard time
reasoning about all of them at once (how functional are they all? what's
their type system like? are they pure?). Then again, I am no functional
programming expert.

Kind regards
Andreas

Razvan Cojocaru :
> Gents, again wikipedia to the rescue
(snip)

Thanks. :)

Already knowing wikipedia's definition, I mentioned the issue because
I've read these blog entries, which some of you may find interesting:

[1] http://www.drmaciver.com/2009/05/a-problem-of-language/
[2] http://www.codecommit.com/blog/scala/is-scala-not-functional-enough
[3] http://james-iry.blogspot.com/2009/05/erlang-is-not-functional.html
[4]
http://james-iry.blogspot.com/2010/03/robert-fischer-finally-admits-that...

Best regards
Andreas

Hello Andreas,

Thank you for your thoughts.

Perhaps my understanding is too shallow. My understanding is that once
libraries and program code are utilizing immutable data structures only,
then recursive algorithms can be executed in parallel. I think this is
also the basis for parallelizing Prolog.

I guess the execution environment needs to support parallel execution,
but that is probably trivial.

However, perhaps the underlying JVM, and the close binding of Scala to
Java libraries, and thus the Scala compiler that makes the integration
with Java possible, "contaminates" the above pure vision, and thus
requires demonstrating that parallelism has worked sufficient many
times.

thanks,

Daniel

p.s. i am wondering whether F# has the same issues, given its
integration into .net.

On Tue, 2010-11-16 at 14:05 +0100, Andreas Flierl wrote:
> Daniel Gross wrote:
>
> > I guess what you are writing is a bit surprising to me. I thought that
> > one of the key selling points for a functional language like Scala, is
> > the easy with which program execution can be distributed across
> > cores/processors.
>
> I would still say it is far easier to do so in Scala than in Java. See
> below for my attempt of reasoning about it.
>
> > It should be possible to clearly establish that a program, or at least,
> > a well designated portion of a program, can be parallelized without any
> > problems.
>
> Again, the key point is in the guarantee, or "clearly establish"ing.
> For example, it is possible to write programs without any runtime type
> errors in a dynamically typed language. Many find it a lot easier in a
> statically typed language, where the compiler verifies your types.
>
> It may be a bit like that in the case of parallelism. The (Scala)
> compiler cannot (or better: currently does not) guarantee thread-safety.
> Therefore you have to rely on testing and/or the programmer telling you:
> this library or part of the program is thread-safe. I personally find
> this a dire situation. So the only way to get to the point where you
> could say that safe parallelization of a program is a "clearly
> establish"ed proptery of that program would be to have it used and
> tested to the point where you at least gain a good level of confidence
> about that property. That's no guarantee, mind you, but it may work out.
>
> Back to the point why I still think Scala makes it quite a bit easier
> to write correct parallel programs.
>
> a) The Scala language allows[1] to create the libraries with the
> necessary abstractions to handle all (or most) of the gory threading
> details for you while keeping the resulting code readable and
> maintainable. Over time, these libraries will mature enough that you can
> take it for "clearly established" that they can be safely used to
> parallelize your program.
>
> b) Functional programming constructs promote immutability and allow for
> composing algorithms from other algorithms. Since these constructs are
> (more or less) battle-tested, you can (more or less) take it as "clearly
> established" that if you compose a safe function with a safe function, a
> safe function will result.
>
> c) The problem remains when is your own function/method/whatever safe
> for parallelization. Currently the only way (in Scala) I am aware of is
> by testing, testing, more testing and probably reasoning about the code,
> preferably with several programmers looking at it. I find this
> sub-optimal. There is no guarantee.
>
> From my experience, a) and b) are what makes correct parallelization in
> Scala easier than in many other languages.
>
> With all of this, please keep in mind that I am neither an expert in
> Scala nor in functional programming. This is all my observation and
> (maybe faulty) reasoning. I'd hope some more proficient people chime in
> here.
>
> Kind regards
> Andreas
>
> [1] I am thinking of resulting brevity and expressivity through
> first-class functions, anonymous functions, partial functions, type
> inference, pattern matching, views etc. etc. I think this is a big thing
> and often understimated.

side effects aren't only a problem in multithreading environments. they (can) make code more complex and less easy to read.

-------- Original-Nachricht --------
> Datum: Tue, 16 Nov 2010 13:32:49 +0200
> Von: Daniel Gross
> An: Luc Duponcheel
> CC: Andreas Flierl , scala-user@listes.epfl.ch
> Betreff: Re: [scala-user] Re: functional/immutable programming question

> Without yet really knowing Scala much (i just started to learn about the
> language), perhaps it's worth defining three classes of programs a) pure
> functional that are guaranteed to have no side-effects and b) mixed
> programs, where side-effects are possible. And b) could be further
> classified into b.1) programs with well localized side effects and b.2)
> hybrid programs.
>
> Perhaps this would imply defining different subsets of Scala and
> libraries use.
>
> Any program of class a) would be guaranteed to run in a parallel
> processing environment, while for b.1) a guarantee is contingent on
> programmer properly dealing with the localized side effects. a program
> of category b.2) has no guarantees and should be run in a non
> parallelized environment.
>
> does this make sense?
>
> thanks,
>
> Daniel
>
> On Tue, 2010-11-16 at 12:18 +0100, Luc Duponcheel wrote:
> > > This example isn't thread-safe, is it? So the side effect escapes
> > even
> > > though the visibility modifier tries to hide it: the client needs to
> > > synchronize externally or restrict itself to one thread. If I recall
> > > correctly Stream cons (or was it List cons?) in the library had this
> > > kind of hidden thread vulnerability.
> >
> > indeed, but, I guess that, in this case, writing a correct algorithm
> > for single threaded usage was already challenging enough :-)
> >
> > > Also, the method is not referentially transparent: it returns two
> > > different values for two identical invocations. In other words,
> > there is
> > > an observable side effect.
> >
> > correct, but even that method could be encapsulated: after all
> > the only thing that the type inferencer has to expose is it's
> > infer method (which is referentially transparent)
> >
> > > All I wanted to say is: it may be much trickier than it seems at
> > first
> > > glance.
> >
> > I agree
> >
> > > Thanks for sharing your opinion
> >
> > thx
> >
> >
> > --
> > __~O
> > -\ <,
> > (*)/ (*)
> >
> > reality goes far beyond imagination
> >
>
>