purely functional (non-monadic) alternatives for Haskell animations in _The Haskell School of Expression_?

Benjamin L.Russell

13 Aug 2008 13 Aug '08

7:53 a.m.

Recently, I mentioned Paul Hudak's _The Haskell School of Expression_ (see http://www.haskell.org/soe/) as an example of using multimedia examples to motivate learning programming in another education-related programming mailing list, plt-scheme, in a thread there entitled "More pedagogic stuff" (see http://list.cs.brown.edu/pipermail/plt-scheme/2008-August/026441.html). In reply, a respondent, Matthias Felleisen, wrote the following (see http://list.cs.brown.edu/pipermail/plt-scheme/2008-August/026445.html):

...

P.S. Yes, I have read Paul's book and I think Haskell has something to it. You may be surprised to learn, however, that world.ss animations are purely functional while Haskell animations (in Paul's book) are actually quasi-imperative. That is, they are using monads and carry the imperativeness on their sleeves.

In response to this claim, does anybody know how to rewrite Hudak's SOE animations so that they do not use monads and are "purely functional?" -- Benjamin L. Russell

Show replies by date

Chaddaï Fouché

13 Aug 13 Aug

8:25 a.m.

New subject: purely functional (non-monadic) alternatives for Haskell animations in _The Haskell School of Expression_?

2008/8/13 Benjamin L. Russell :

...

...
P.S. Yes, I have read Paul's book and I think Haskell has something to it. You may be surprised to learn, however, that world.ss animations are purely functional while Haskell animations (in Paul's book) are actually quasi-imperative. That is, they are using monads and carry the imperativeness on their sleeves.

In response to this claim, does anybody know how to rewrite Hudak's SOE animations so that they do not use monads and are "purely functional?"

First, monad /= imperative It is important to establish this distinction which doesn't seem to be very clear in some minds... The IO monad allows imperative actions, the ST monad too, the Maybe Monad doesn't, neither does the List Monad... The State monad can be argued either way but all it does is make easier to use a pattern you often meet in non-monadic functional programming. The confusion is helped along by the do-notation in Haskell which definitely looks like imperative programming, but is only sugar over a purely functional form. Now, I don't know SOE very well and it is very possible that its description of animation is imperative but animations imply to handle time and order of operations anyway, so I don't really see how you could implement that in a more purely functional style, a monad is very good at describing ordered actions with a light syntax in a functional context. (Another aspect is if the details of the rendering of the animation is interleaved with the description, that is a more interesting subject, on which we could compare the code in world.ss and SOE) -- Jedaï

Bayley, Alistair

8:43 a.m.

New subject: purely functional (non-monadic) alternativesfor Haskell animations in _The Haskell School of Expression_?

...

From: beginners-bounces@haskell.org [mailto:beginners-bounces@haskell.org] On Behalf Of Chaddaï Fouché

2008/8/13 Benjamin L. Russell :

...
...
P.S. Yes, I have read Paul's book and I think Haskell has something to it. You may be surprised to learn, however, that world.ss animations are purely functional while Haskell animations (in Paul's book) are actually quasi-imperative. That is, they are using monads and carry the imperativeness on their sleeves.

In response to this claim, does anybody know how to rewrite Hudak's SOE animations so that they do not use monads and are "purely functional?"

First, monad /= imperative It is important to establish this distinction which doesn't seem to be very clear in some minds...

I think Matthias Felleisen probably understands this, but I could be wrong... I had a quick scan of the SOE source and it looks as though all of the graphics operations are in IO (). I don't see why you couldn't rearrange it so that describing shapes was purely functional, while rendering was still IO () (required by OpenGL, I assume), but it looks like it could be quite a bit of work. For animation, perhaps look at Conal Elliot's functional reactive work, but I don't know how usable it is: http://conal.net/ Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

Chaddaï Fouché

9:14 a.m.

New subject: purely functional (non-monadic) alternativesfor Haskell animations in _The Haskell School of Expression_?

2008/8/13 Bayley, Alistair :

...

...
First, monad /= imperative It is important to establish this distinction which doesn't seem to be very clear in some minds...

I think Matthias Felleisen probably understands this, but I could be wrong...

I think so too, but we're on Haskell-beginners and the formulation was much too ambiguous to let it pass, I would prefer that beginners in Haskell don't start with the idea that Monad are always imperative, it's already too current a misunderstanding.

...

I had a quick scan of the SOE source and it looks as though all of the graphics operations are in IO (). I don't see why you couldn't rearrange it so that describing shapes was purely functional, while rendering was still IO () (required by OpenGL, I assume), but it looks like it could be quite a bit of work.

That's unfortunate. Of course IO (or some FRP hiding the IO) is still required to do the rendering, but it would be much nicer to split those concerns. -- Jedaï

Benjamin L.Russell

14 Aug 14 Aug

1:10 a.m.

New subject: purely functional (non-monadic) alternativesfor Haskell animations in _The Haskell School of Expression_?

On Wed, 13 Aug 2008 14:14:46 +0100, "Chaddai Fouche" wrote:

...

2008/8/13 Bayley, Alistair :

...
...
First, monad /= imperative It is important to establish this distinction which doesn't seem to be very clear in some minds...

I think Matthias Felleisen probably understands this, but I could be wrong...

I think so too, but we're on Haskell-beginners and the formulation was much too ambiguous to let it pass, I would prefer that beginners in Haskell don't start with the idea that Monad are always imperative, it's already too current a misunderstanding.

Can you recommend any specific examples to illustrate this point to a programmer/educator from a Scheme background arguing that specific libraries in world.ss are more functional than the monadic examples for animations in SOE? If possible, I would like to write a rebuttal to his claim, using specific examples.

...

...
I had a quick scan of the SOE source and it looks as though all of the graphics operations are in IO (). I don't see why you couldn't rearrange it so that describing shapes was purely functional, while rendering was still IO () (required by OpenGL, I assume), but it looks like it could be quite a bit of work.

That's unfortunate. Of course IO (or some FRP hiding the IO) is still required to do the rendering, but it would be much nicer to split those concerns.

That's probably the point that Felleisen was addressing. If functions have any side-effects, then they aren't purely functional, but in order to perform rendering, side-effects would be necessary in both Haskell and Scheme, so this can't be his point. Therefore, he must be referring to other functions written in a more purely functional style in world.ss than in SOE. In order to address his point, they would probably be need to be rewritten in a purely functional style. -- Benjamin L. Russell

Federico Brubacher

21 Aug 21 Aug

9:32 a.m.

New subject: purely functional (non-monadic) alternativesfor Haskell animations in _The Haskell School of Expression_?

Hey Benjamin, I solved the quiz myself but would you mind posting your code again so I can compare ?? Thanks a ton Federico On Thu, Aug 14, 2008 at 2:10 AM, Benjamin L. Russell

...

wrote:

...

On Wed, 13 Aug 2008 14:14:46 +0100, "Chaddai Fouche" wrote:

...
2008/8/13 Bayley, Alistair :

...
...
First, monad /= imperative It is important to establish this distinction which doesn't seem to be very clear in some minds...

I think Matthias Felleisen probably understands this, but I could be wrong...

I think so too, but we're on Haskell-beginners and the formulation was much too ambiguous to let it pass, I would prefer that beginners in Haskell don't start with the idea that Monad are always imperative, it's already too current a misunderstanding.

Can you recommend any specific examples to illustrate this point to a programmer/educator from a Scheme background arguing that specific libraries in world.ss are more functional than the monadic examples for animations in SOE?

If possible, I would like to write a rebuttal to his claim, using specific examples.

...
...
I had a quick scan of the SOE source and it looks as though all of the graphics operations are in IO (). I don't see why you couldn't rearrange it so that describing shapes was purely functional, while rendering was still IO () (required by OpenGL, I assume), but it looks like it could be quite a bit of work.

That's unfortunate. Of course IO (or some FRP hiding the IO) is still required to do the rendering, but it would be much nicer to split those concerns.

That's probably the point that Felleisen was addressing. If functions have any side-effects, then they aren't purely functional, but in order to perform rendering, side-effects would be necessary in both Haskell and Scheme, so this can't be his point. Therefore, he must be referring to other functions written in a more purely functional style in world.ss than in SOE. In order to address his point, they would probably be need to be rewritten in a purely functional style.

-- Benjamin L. Russell

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

-- Federico Brubacher www.fbrubacher.com Colonial Duty Free Shop www.colonial.com.uy

Benjamin L.Russell

10:37 p.m.

New subject: purely functional (non-monadic) alternativesfor Haskell animations in _The Haskell School of Expression_?

On Thu, 21 Aug 2008 10:32:29 -0300, "Federico Brubacher" wrote:

...

Hey Benjamin, I solved the quiz myself but would you mind posting your code again so I can compare ??

Which quiz? -- Benjamin L. Russell

6115

Age (days ago)

6124

Last active (days ago)

List overview

Download

6 comments

4 participants

participants (4)

Bayley, Alistair
Benjamin L.Russell
Chaddaï Fouché
Federico Brubacher