[Haskell-cafe] Tetris

[Laurent Deniau]

Conal Elliott wrote:
> On Nov 21, 2007 3:49 AM, Laurent Deniau <laurent.deniau at cern.ch 
> <mailto:laurent.deniau at cern.ch>> wrote:
> 
>  > Peter Verswyvelen wrote:
>  > > Conal Elliott wrote:
>  > >> Moreover, functional programming makes it easy to have much more 
> state
>  > >> than imperative programming, namely state over *continuous* time.  The
>  > >> temporally discrete time imposed by the imperative model is pretty
>  > >> puny in comparison.  Continuous (or "resolution-independent") time 
> has
>  > >> the same advantages as continuous space: resource-adaptive, scalable,
>  > >> transformable.
>  > > Yes, that's true, but isn't that also the problem with FRP? I mean, 
> most
>  > > of the papers I'm reading about (A)FRP indicate that no matter how 
> nice
>  > > it is to have the continuous time model
> 
>  > I agree with Conal, it's not a continuous time model but a
>  > resolution-independent time model.
> 
> What do mean by resolution-independent vs continuous? 

I mean time may or may not be part or the model in FRP.

> I meant them more-or-less synonymously.  Semantically, there's no notion 
> of resolution.  When it's time to introduce a resolution for discrete 
> rendering, there's no resolution imposed by the model.

Right. This is why I do not see the relation with the number of bits in 
a float. Time could be represented by states, in the sens of a state 
machine with asynchronous events.

>  >                                     The reason it that Arrows (like
>  > Monads) encapsulate the sequence of transitions.  Unless the time is a
>  > parameter of the transition, it is independent of the time (resolution),
>  > but still captures its ordered nature.
> 
> I'm confused again. I don't think of Arrow as implying transitions at all.

I call a transition the operator >>= for Monad, and arr for Arrow. I was 
maybe not clear in this point. The correct wording might be a computation.

>  > > to get fine grained control
>  > > over execution times and resources, one needs to fall back to the
>  > > discrete delta-time approach?
> 
>  > If you need synchronization, yes.
> 
> Why?  What about synchronization implies discretness in the model?

Because it requires either specific states which are aware of each other 
(asynchronous events), or a known delta-time. How do you synchronize 
continuous events (I would says more continuous processes) ?

Regards,

ld.