Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: Avoid Case Analyses (Rustom Mody)
2. Re: FRP (Heinrich Apfelmus)
----------------------------------------------------------------------
Message: 1
Date: Tue, 16 Oct 2012 07:33:20 +0530
From: Rustom Mody <[email protected]>
Subject: Re: [Haskell-beginners] Avoid Case Analyses
To: "Costello, Roger L." <[email protected]>
Cc: "[email protected]" <[email protected]>
Message-ID:
<caj+teodxn92j7heuigxq21cyfqeby11p3ag1+ix8oevgfsq...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Sun, Oct 7, 2012 at 3:17 PM, Costello, Roger L. <[email protected]>wrote:
> Hi Folks,
>
> "Programs that avoid case analyses are clearer and simpler than those that
> use case analyses."
If you believe that you will surely enjoy the beautiful 4-lines-of assembly
that http://prog21.dadgum.com/27.html starts with. If... Else?
Rusi
--
http://blog.languager.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20121016/33030572/attachment-0001.htm>
------------------------------
Message: 2
Date: Tue, 16 Oct 2012 10:20:47 +0200
From: Heinrich Apfelmus <[email protected]>
Subject: Re: [Haskell-beginners] FRP
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Dear Miguel,
sorry for the late reply, I have been traveling in the last weeks.
Miguel Negrao wrote:
> Heinrich Apfelmus escreveu:
>> Miguel Negrao wrote:
>>> Thanks for the explanation. I was wondering, how would one translate
>>> this Yampa code into reactive-banana:
>>>
>>> fallingBall :: Pos -> Vel -> SF () (Pos, Vel)
>>> fallingBall y0 v0 = proc () -> do
>>> v <- (v0 +) ?<< integral -< -9.81
>>> y <- (y0 +) ?<< integral -< v
>>> returnA -< (y, v)
>>> fallingBall? :: Pos -> Vel -> SF () ((Pos,Vel), Event (Pos,Vel))
>>> fallingBall? y0 v0 = proc () -> do
>>> yv@(y, _) <- fallingBall y0 v0 -< ()
>>> hit <- edge -< y <= 0
>>> returnA -< (yv, hit ?tag? yv)
>>> bouncingBall :: Pos -> SF () (Pos, Vel)
>>> bouncingBall y0 = bbAux y0 0.0
>>> where
>>> bbAux y0 v0 = switch (fallingBall? y0 v0) $ \(y,v) -> bbAux y
>>> (-v)
>>
>> [...]
>
> Yes, looking at the internals of Yampa I had seen that they have
> internal time management, but my question was more specifically if there
> was a way to have a function like bbAux which recursively switches into
> itself. Would it be possible with the new dynamic switching ? I find
> that way of expressing the discontinuous changes quite elegant.
Yes, it's possible, but it will feel alien. There are two reasons for that:
1. switchB is meant to change the behavior whenever the event occurs,
not just on the first occurrence. The bbAux function is recursive
precisely because only the first occurrence causes a switch in Yampa.
Maybe reactive-banana should adopt this approach as well, but I'm
undecided.
2. In Yampa, fallingBall is a signal function, which means that it has
no fixed starting time. In contrast, behaviors in reactive-banana
usually have a fixed starting time so that they can accumulate state. Of
course, reactive-banana also has behaviors that have a variable starting
time, but they are a separate type. In other words, you have to model it as
fallingBall :: Pos -> Vel -> AnyMoment Behavior Pos
So, modeling this using dynamic event switching is possible, but these
two points mean that it's probably much easier to use a recursive
event/behavior combination like in the Animation.hs example or Andreas
Bernstein's breakout code.
As you can see, dynamic event switching is still uncharted territory,
there are a lot of design patterns to discover.
> Even
> more elegant seems to be the instantaneous impulses (modeling of
> distributions or dirac deltas) although I couldn?t find any functioning
> code that implements it [1].
Well, I do not think that mixing continuous signals and discrete events
in this way is a good idea. Having two separate types gives you more
information to reason with: Event can only be discrete, Behavior can
only be continuous.
I would like to stress again that the design space for FRP is huge,
which is good. But the ultimate goal is to simplify a certain class of
code, namely GUIs, audio and games, and I feel that few, if any FRP
approaches have been tested enough against these "hard" targets. I mean,
if I use FRP to implement a game and the code is just as messy as the
imperative version, then I may wonder why I am doing this at all. So
far, I only know of Conal who makes a convincing argument for his style
Conal Elliott. Declarative Event-Oriented Programming.
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.31.1064
(Interestingly, he doesn't really use dynamic event switching in this
instance.)
Simplicity also hinges on a lot of details, see for instance my
discussion on GUI elements
http://apfelmus.nfshost.com/blog/2012/03/29-frp-three-principles-bidirectional-gui.html
Conal's decision to allow recursion between Event and Behavior is one of
these very important details.
Best regards,
Heinrich Apfelmus
--
http://apfelmus.nfshost.com
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 52, Issue 21
*****************************************
