FRP interface reactiveOf #486

nomeata · 2017-05-22T02:23:19Z

This patch allows users to create interactions by defining a FRP
program, based on the reflex library. The dependency on reflex is
optional, and enabled with -freflex.

This is a result of some hacking with the reflex people at the Compose
Unconference (but all the code in this patch is mine).

A mode where even reactive collaborations are supported depends on some
fancy new feature in reflex, which would allow stats to be reset.

This might be of interest to @ryantrinkle and the other reflex guys.

nomeata · 2017-05-22T02:26:05Z

@ali-abrar

cdsmith

Cool!

cdsmith · 2017-05-22T03:28:36Z

codeworld-api/codeworld-api.cabal

@@ -36,6 +40,12 @@ Library
                       cereal               >= 0.5.4 && < 0.6,
                       cereal-text          >= 0.1.0 && < 0.2

+  if flag(reflex)


Do you think a flag is the right answer here? What exactly is the goal?

If it's the additional dependency, I don't have any concerns about it. I'm happy to just depend on reflex without the flag.

If you're trying to dissuade usage until you're more confident in the API, consider a WARNING pragma instead? Then people could still try it out on the live site.

If it's about polluting the API, consider a different public module, like CodeWorld.Reactive, instead?

Or is there some reason we should be worried about pushing this live?

nomeata · 2017-05-22T14:13:46Z

If it's the additional dependency, I don't have any concerns about it. I'm happy to just depend on reflex without the flag.

That was my worry. But if that is not a problem, I can remove it.

Caveat: I have built reflex from github. I guess I should test if this actually works with reflex from hackage…

I think the interface is pretty much the only sensible (the other option would be a Behaviour Time, but Ryan advised against it).

I am also less worried about polluting the API, it is the “advanced” API anyways.

ryantrinkle · 2017-05-22T14:24:14Z

I'll get the new version of Reflex up on hackage ASAP. I'd recommend holding off on upstreaming this until then, as there have been some breaking changes.

This patch allows users to create interactions by defining a FRP program, based on the reflex library. The dependency on reflex is optional, and enabled with -freflex. This is a result of some hacking with the reflex people at the Compose Unconference. A mode where even reactive collaborations are supported depends on some fancy new feature in reflex, which would allow stats to be reset.

@ryantrinkle

to keep CodeWorld/Driver clean (and to give @ryantrinkle an idea about what kind of interface I would have preferred here :-)).

nomeata · 2017-05-22T14:44:05Z

I'd recommend holding off on upstreaming this until then, as there have been some breaking changes.
Ok, will do . I changed the version range to require 0.5.

Ryan, f93f42c has a sketch of the simple interface I would like to see. The downside is that it hard-codes the number of events and behaviors, and I am temped to pull out heterogeneous lists to fix that … but then it would not longer be simple…

ali-abrar · 2017-05-22T14:53:45Z

Given that events can be merged and fanned out, maybe you can get away with just one event for the simple host example.

nomeata · 2017-05-22T15:00:15Z

I was wondering: Is there a performance penalty of merging and fanning out?

Also, this eventTriggerRef can contain a Maybe. If this is Nothing, does this mean that nobody is listening to this event? If CodeWorld could see that the time event is not used, it could avoid looping (it already does that in the other drivers, by some tricks involving comparing StableNames).

But that would break if the two events were merged and fanned out, right?

ryantrinkle · 2017-05-22T15:13:07Z

There's not much of a penalty for fanning out - about the same as traversing any other event. The fan primitive is designed to be lazy, so even if you have an infinite number of keys in the potential input, you can still deliver them efficiently. The overhead is something like O(log(number of distinct keys that have been subscribed to)).

…

On Mon, May 22, 2017 at 11:00 AM, Joachim Breitner ***@***.*** > wrote: I was wondering: Is there a performance penalty of merging and fanning out? Also, this eventTriggerRef can contain a Maybe. If this is Nothing, does this mean that nobody is listening to this event? If CodeWorld could see that the time event is not used, it could avoid looping (it already does that in the other drivers, by some tricks involving comparing StableNames ). But that would break if the two events were merged and fanned out, right? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#486 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABGlYJE7qOunf3EbGEQa5K3X5ZOrBPbSks5r8aMCgaJpZM4Nh0DV> .

cdsmith · 2017-05-22T20:43:26Z

@nomeata @ryantrinkle Is there a fundamental reason why making time a Behavior is a bad idea? It seems like the obvious choice to me. Is this just a matter of the implementation being awkward, or is there something wrong with the abstraction?

ryantrinkle · 2017-05-22T21:02:45Z

Defining time as a Behavior has strange semantics in some subtle ways. The most important of these is that many of the things you'd like to define won't work if time is a Behavior - in particular, you can't do something like "Fire an Event when this Behavior crosses 0" and then invoke it on now - myDeadlineBehavior, because Behaviors are pull-driven, and thus can't spontaneously push things.
It would also require (much) more information about the function the Behavior represents than we actually have. Discontinuous functions would be quite challenging to deal with.

Now, you could certainly accumulate an Event t DiffTime (or similar) to create a Behavior t Time, but this Behavior would move stepwise, which might not be expected. Also, the natural way in Reflex would be to have the Behavior represent the last frame's time, not the current frame's time, which might be confusing for some users. It would be possible to update the Behavior in one frame, and then fire the delta time Event in another frame - Reflex guarantees that Behavior updates like that aren't observable by the program, so I think the semantics would work out. This would probably be the way to go if you wanted to provide now :: Behavior t Time. The Event t DiffTime would still need to be provided, so that local state can be updated and things like that (Behavior changes can't cause that in Reflex).

cdsmith · 2017-05-22T21:22:33Z

Okay, I see. Yeah, I guess if you had a Behavior for time, then you'd also need an oftenEnough :: Event t () that fires every frame, so you could start from that and filter down to an Event that captures important time thresholds. And now by trying to simply one of the two components, we've ended up with three components instead...

ryantrinkle · 2017-05-22T21:25:19Z

@cdsmith Yep! Eventually, if we did a whole lot of work on continuous-time FRP (which Reflex is designed to be consistent with, as an extension), we might be able to provide something cleaner. However, I think making continuous time FRP nice to work with is still an open problem, and Reflex's approach of "time is just a totally-ordered set" seems to be great for most kinds of applications.

cdsmith · 2017-05-26T19:04:08Z

@nomeata Do you prefer to merge this, or wait for Reflex changes? If the former, I'd prefer not to define a module in the Reflex hierarchy here. If that's just interim and you don't want to merge this, that's fine. Just checking.

ryantrinkle · 2017-05-26T19:05:40Z

Oh, yeah, let's get Reflex.SimpleHost into Reflex. I'm getting close to having 0.5 ready for release, and I think I could stick that in quite easily. @nomeata Thoughts?

nomeata · 2017-05-26T19:55:11Z

There is no reason to hurry with this PR, so moving this module (or something similar) to reflex first, and then adjusting this branch to build on the release 0.5, makes sense.

cdsmith · 2018-10-09T16:22:23Z

@nomeata @ryantrinkle

I have a renewed interest in merging something like this now. I'm interested in turning http://code.world/haskell into a more general-purpose UI for building Haskell code with commonly used APIs. The first three on my list are gloss, reflex, and diagrams.

Any thoughts on the right path forward here? There was some discussion about making changes to reflex to make this easier, and of this not working correctly with reflex. I'm happy to poke around a bit myself, but I may as well ask first.

nomeata · 2018-10-09T22:13:43Z

I think the question was just whether simpleReflexHost ought to live in reflex, but I don’t think you should be held up by this.

hpacheco · 2019-07-11T12:29:31Z

I have a renewed interest in merging something like this now. I'm interested in turning http://code.world/haskell into a more general-purpose UI for building Haskell code with commonly used APIs. The first three on my list are gloss, reflex, and diagrams.

@cdsmith I had already been doing some hacking on the gloss front: https://github.com/hpacheco/codeworld-api-gloss

cdsmith reviewed May 22, 2017

View reviewed changes

cdsmith changed the title ~~FRP interface reativeOf~~ FRP interface reactiveOf May 22, 2017

nomeata added 3 commits May 22, 2017 10:36

reactiveOf: Do not bother with a Cabal flag

f2194a8

Pull out Reflex boiler plate code into its own module

f93f42c

to keep CodeWorld/Driver clean (and to give @ryantrinkle an idea about what kind of interface I would have preferred here :-)).

nomeata force-pushed the reflex branch from 6640786 to f93f42c Compare May 22, 2017 14:41

cdsmith added 2 commits May 26, 2017 13:07

Merge branch 'master' into reflex

c799738

Merge branch 'master' into reflex

f56094c

cdsmith mentioned this pull request Jul 21, 2017

Encapsulated applications #492

Open

cdsmith mentioned this pull request Jan 29, 2019

Handling randomness in Haskell mode #806

Closed

cdsmith closed this in aa9b7aa Jun 30, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

FRP interface reactiveOf #486

FRP interface reactiveOf #486

nomeata commented May 22, 2017 •

edited

Loading

nomeata commented May 22, 2017

cdsmith left a comment

cdsmith May 22, 2017

nomeata commented May 22, 2017

ryantrinkle commented May 22, 2017

nomeata commented May 22, 2017

ali-abrar commented May 22, 2017

nomeata commented May 22, 2017

ryantrinkle commented May 22, 2017 via email

cdsmith commented May 22, 2017

ryantrinkle commented May 22, 2017

cdsmith commented May 22, 2017

ryantrinkle commented May 22, 2017

cdsmith commented May 26, 2017

ryantrinkle commented May 26, 2017

nomeata commented May 26, 2017

cdsmith commented Oct 9, 2018

nomeata commented Oct 9, 2018

hpacheco commented Jul 11, 2019

FRP interface reactiveOf #486

FRP interface reactiveOf #486

Conversation

nomeata commented May 22, 2017 • edited Loading

nomeata commented May 22, 2017

cdsmith left a comment

Choose a reason for hiding this comment

cdsmith May 22, 2017

Choose a reason for hiding this comment

nomeata commented May 22, 2017

ryantrinkle commented May 22, 2017

nomeata commented May 22, 2017

ali-abrar commented May 22, 2017

nomeata commented May 22, 2017

ryantrinkle commented May 22, 2017 via email

cdsmith commented May 22, 2017

ryantrinkle commented May 22, 2017

cdsmith commented May 22, 2017

ryantrinkle commented May 22, 2017

cdsmith commented May 26, 2017

ryantrinkle commented May 26, 2017

nomeata commented May 26, 2017

cdsmith commented Oct 9, 2018

nomeata commented Oct 9, 2018

hpacheco commented Jul 11, 2019

nomeata commented May 22, 2017 •

edited

Loading