Proposal: One semantics to bind them all about reactive-banana HOT 5 CLOSED

Hmm. I'm not quite sure I see the benefit of this. Reactive.Banana.Primitive is the real semantics here; the others are just libraries built on top. Or, rather: What is the difference between Reactive.Banana.Primitive + Reactive.Banana.Updated and Reactive.Banana + Reactive.Banana.Incremental?

If you expose the representations, then you're not really experimenting with a new semantics, because e.g. you can observe the Event in Reactive.Banana.Updated.Behavior; you don't have the semantic advantages of continuous-in-pure-code that putting sample in NetworkDescription gives you. But if you don't expose them, then the different semantics can't interoperate at all, and so I don't see the advantage over just maintaining separate git branches to experiment, rather than baking it into the library.

Additionally, the choice of the primitive types and semantics would be difficult; I think it would have the effect of making it seem undesirable to experiment with semantics that can't be implemented nicely without changing the primitives. Plus, it would limit the amount of optimisations that can be done for specific semantics, which could otherwise be a factor in the decision of which to adopt as official.

It's true that experimenting with new semantics has a fairly high upfront cost at present, but I'd like to think that drastically changing the core semantics of the implementation won't happen on a regular basis; I appreciate reactive-banana's conservatism in valuing known-working but perhaps slightly underpowered interfaces over experimental ones. Of course, that's not to say it shouldn't innovate, but that perhaps its process of innovation should be careful enough that once something is finalised and made official, it can be relied on for a decent length of time.

from reactive-banana.

I basically agree with the proposal but I think that there are only two roads that it could go down that would be sensible.

The first road is to make any of the semantics definable in terms of any of the other semantics. This would be difficult and might not even be possible, but it is the only approach that would give you the freedom to change what the most "primitive" semantics are in the future.

The second road is to define a primitive semantics and treat the other semantics as essentially libraries built on top of these semantics. This takes away your freedom to redefine the primitive semantics (while maintaining backwards compatibility), but it still gives you freedom to optimize one of the libraries built on top of it if it turns out to be the dominant use case because you could still modify the core data structures on which the primitive semantics are built so that they have more optimal support for the library. This does assume, though, that the core data structures remain opaque, and if this is not your intention then you will not have this freedom if you are worried about preserving backwards compatibility with respect to them.

from reactive-banana.

The discussion with ehird on #25 has caused me to see a potential problem with the "second road" I mentioned above: Users will not typically be using reactive-banana directly but rather will be using it combined with some other package that provides an event loop, and it is not clear what semantics the other package should be expected to support. If it only supports the most primitive semantics, then the user may have to do a lot of lifting in order to use the package in the realm of their own preferred semantics. If it supports all of the higher-level libraries, though, then that places a fairly large burden on the maintainer of that package.

Having said that, the burden of lifting placed on users might not be that big of a deal since they would only need to lift external events, and most of their code might be spent on internal events instead.

from reactive-banana.

Ok, so the takeaway for me here is that we don't want a proliferation of various semantics, but being open to experiments is desirable. I have made a new subfolder Reactive.Banana.Experimental that may contain these experiments, in the hope that the modules contained within either go up or drop out.

In this particular case, issue #25 gets a new module Reactive.Banana.Experimental.Calm while issue #22 is baked into the core model.

I'll document this approach in the wiki before closing this issue.

from reactive-banana.

Documented. Time to close the issue, but feel free to discuss or reopen.

from reactive-banana.