[Haskell-cafe] Re: How to do this in FP way?

Achim Schneider barsoap at web.de
Mon Jun 16 23:08:36 EDT 2008


Thomas Davie <tom.davie at gmail.com> wrote:

> 
> On 16 Jun 2008, at 19:24, Achim Schneider wrote:
> 
> > Thomas Davie <tom.davie at gmail.com> wrote:
> >
> >>
> >> On 16 Jun 2008, at 18:28, Achim Schneider wrote:
> >>
> >>> Thomas Davie <tom.davie at gmail.com> wrote:
> >>>
> >>>>>
> >>>>> One half of all Haskell coders will tell you that mutable state
> >>>>> isn't a
> >>>>> good starting point to learn Haskell, the other half will tell
> >>>>> you the same because they want to be cool kids, too.
> >>>>
> >>>> And the one left over will point out that he asked how to do this
> >>>> the FP way, not the imperative way?
> >>>>
> >>> There's no difference, as you can't do time-accounting non-strict
> >>> and still expect it to give meaningful results: I'm merely trying
> >>> to be helpful. None of the other solutions allow for the IO Monad.
> >>
> >> Firstly, I'd phrase that differently -- the IO Monad doesn't allow
> >> for the other solutions -- the other solutions are the truly
> >> functional ones.  Secondly, I'm curious as to why you think that
> >> the two are incompatible, are you saying that for any meaningful
> >> kind of computation we need to resort to IORefs?  I'd strongly
> >> contest that idea.
> >>
> > We have to resort to IO actions to get the time, and to IORefs
> > because we need to chain up different calls to getCurrentTime using
> > the IO Monad. The rest of the program can work with whatever you
> > like best.
> 
> And in what way is this incompatible with either FRP as pierre  
> suggested, or with generating an infinite list of times at which we  
> call the function, and scanning it to find the differences?
> 
Argh. I should not have copypasted that GLUT code, as it introduces
IORefs not because they're 100% necessary but because that code is
called back from C. My main point is that his task, if it is as simple
as he described it, will stay imperative. My point also depends on that
code being part of a main driver loop, as you see it in games: It's
just the thing I instantly recognised in his code.

Consider this:

update :: MyState -> Int -> MyState
draw :: MyState -> IO ()

mainLoop :: MyState -> Int -> IO ()
mainLoop st old = do
	now <- getTimeOfDay
	let td = now - old
	    st' = update st td
	draw st'
	mainLoop st' now

This, to my understanding of things, is imperative, although there's no
IORef to be found. OTOH, recursing like this is "the FP way" to do it.
mainLoop's arguments are variables to my eyes.

-- 
(c) this sig last receiving data processing entity. Inspect headers for
past copyright information. All rights reserved. Unauthorised copying,
hiring, renting, public performance and/or broadcasting of this
signature prohibited. 



More information about the Haskell-Cafe mailing list