withNextE seems to allow occurrences' values to depend on occurrences which haven't yet occurred. Of course, it doesn't actually allow time travel. If the occurrence is not yet computed, presumably it will block until it does. Still, this is problematic theoretically. It allows "simulations" to be constructed which contain reverse causality (if the simulation makes all the input occurrences available immediately). Is this a case of making the framework a little too powerful? -- Robin
Hi Robin,
David Sankel & I came up with withNextE at one point and didn't end up using
it. I like the idea of experimenting with reverse causality. And yeah, I
might want to remove it at some point. If you think of a use, please let us
all know.
- Conal
On Fri, Nov 21, 2008 at 6:23 AM, Robin Green
withNextE seems to allow occurrences' values to depend on occurrences which haven't yet occurred.
Of course, it doesn't actually allow time travel. If the occurrence is not yet computed, presumably it will block until it does.
Still, this is problematic theoretically. It allows "simulations" to be constructed which contain reverse causality (if the simulation makes all the input occurrences available immediately). Is this a case of making the framework a little too powerful?
-- Robin _______________________________________________ Reactive mailing list Reactive@haskell.org http://www.haskell.org/mailman/listinfo/reactive
On Fri, Nov 21, 2008 at 9:23 AM, Robin Green
withNextE seems to allow occurrences' values to depend on occurrences which haven't yet occurred.
Of course, it doesn't actually allow time travel. If the occurrence is not yet computed, presumably it will block until it does.
Still, this is problematic theoretically. It allows "simulations" to be constructed which contain reverse causality (if the simulation makes all the input occurrences available immediately). Is this a case of making the framework a little too powerful?
In the context of an event, we can distinguish between the time of an
occurrence (t), the time when the occurrence's time is computable
(ct), and the time when the occurrence's value is computable (cv).
Running a real-time simulation on an event, we would certainly want it
to be the case that for all occurrences, cv -- Occurs whenever a new piece comes on the screen.
newPiece :: Event Piece The time when the value of these occurrences is computable (cv) could
be when the game starts, since it is just a random sequence of pieces.
This is one case where withNextE could make sense (but where withNextE
. withTimeE_ probably wouldn't).
Consider an implementation of a preview pane. -- Preview of next piece
preview :: Behavior Geometry
preview = fmap toGeo (stepper (firstE newPiece) (withNextE_ newPiece)) David
--
David Sankel
On Fri, Nov 21, 2008 at 7:23 AM, Robin Green
withNextE seems to allow occurrences' values to depend on occurrences which haven't yet occurred.
Of course, it doesn't actually allow time travel. If the occurrence is not yet computed, presumably it will block until it does.
Still, this is problematic theoretically. It allows "simulations" to be constructed which contain reverse causality (if the simulation makes all the input occurrences available immediately). Is this a case of making the framework a little too powerful?
I have been on-and-off experimenting with formalizations of FRP in which this function would be illegal -- i.e. semantically meaningless. Causality is one of the two big problems I see with the semantics. I believe that "blocking thunks" can be of huge benefit to an implementation since they are exposed to the optimizer. However, I think it's a bad idea to ever expose a blocking thunk to a user of the reactive library. I played with a "time" module for a little while that encoded time relations in the type system, in order that you had to prove you were after an occurrence of a future in order to get its value. I still think that a reactive implementation ought to be based on an abstraction like this, so it comes with at least one sort of correctness proof.
participants (4)
-
Conal Elliott -
David Sankel -
Luke Palmer -
Robin Green