"Normalized" Flapjax API for ClojureScript

[Micha Niskin]

I found it a little bit difficult to use Flapjax in cljs, because some methods are defined on prototypes and some are defined as plain functions. So I wrote this little guy to expose Flapjax as just functions, which is how you'd want to do things in cljs. Maybe it'll be of use to someone here: https://gist.github.com/4151470

Thanks!

[Christopher Meiklejohn]

On Sunday, December 2, 2012 1:02:16 PM UTC-5, Micha Niskin wrote:

I found it a little bit difficult to use Flapjax in cljs, because some methods are defined on prototypes and some are defined as plain functions. So I wrote this little guy to expose Flapjax as just functions, which is how you'd want to do things in cljs. Maybe it'll be of use to someone here: https://gist.github.com/4151470

Thanks!

Hi Micha,

For what it's worth, I've been actively working on a ClojureScript-native library which implements the ideas in Flapjax, as well as changes the API in some places where we can take advantage of things like the threading macro, and polymoprhic dispatch with protocols.  I'm partially there; I've outlined in the README the items which are currently outstanding.

I'm looking for help, if you're interested.

https://github.com/cmeiklejohn/shafty

http://cmeiklejohn.github.com/shafty/

- Chris

[Micha Niskin]

I've seen shafty, but it does not do FRP, as far as I can tell. It appears to be a watcher-based event propagation thing. Flapjax is useful because it provides glitch-free properties of FRP. Watchers, on the other hand, merely propagate events without in any way guaranteeing any sort of glitch-elimination. While it would be nice to have a Flapjax-compatible API for doing FRP in clojure itself, I don't see much advantage to rewriting Flapjax in cljs, if it can be avoided. Does shafty provide any functionality that Flajpax itself cannot provide?

--

Micha Niskin

--
Flapjax home page: www.flapjax-lang.org
Flapjax list: groups.google.com/group/flapjax
Post: fla...@googlegroups.com
Unsubscribe: flapjax-u...@googlegroups.com

[Christopher Meiklejohn]

On Sunday, December 2, 2012 1:12:13 PM UTC-5, Micha Niskin wrote:

I've seen shafty, but it does not do FRP, as far as I can tell. It appears to be a watcher-based event propagation thing.

You are correct.  It is watches-based right now.  However, I do not believe it's correct in saying it's not FRP because of it's "glitchiness", as this property is not an essential property of functional reactive programming. 

 

Flapjax is useful because it provides glitch-free properties of FRP. Watchers, on the other hand, merely propagate events without in any way guaranteeing any sort of glitch-elimination.

This is true.  I've included on the README that I'm going to explore glitch-free propagation through the use of a priority queue, time stepping, and breadth-first evaluation.  The data structures I've modeled in in CLJS are extremely close to the data structures used in Flapjax itself (by means of modeling sicks and sources, etc.), and it should be trivial to replace the watches based approach with this one.  

 

While it would be nice to have a Flapjax-compatible API for doing FRP in clojure itself, I don't see much advantage to rewriting Flapjax in cljs, if it can be avoided. Does shafty provide any functionality that Flajpax itself cannot provide?

One reason for modeling this in CLJS is because I feel that most of the components and approaches should work fine in Clojure itself (with the exception of DOM manipulation), and I'd like to see it exist there.  CLJS is a good starting point, and I feel the library will be most useful on the web.

- Chris

[Shriram Krishnamurthi]

I'm happy to hear arguments to the contrary, but:

> However, I do not believe it's correct in saying it's not FRP
> because of it's "glitchiness", as this property is not an essential
> property of functional reactive programming.

That's bunk.

The problem with glitches is this: you can obtain a value from the
program that is inconsistent with its semantics (which, in a
transparent FRP language like FrTime or compiled Flapjax, is defined
in terms of the base language). This makes any non-trivial static
reasoning about the program essentially impossible. You can't perform
substitutions, establish invariants, etc., and if you do, you would be
reasoning faultily. I cannot think of anything more antithetical to
FRP than that.

Thus, to me, it is the basic safety condition for a usable FRP
language. Let me now qualify "usable".

One alternative is to redefine the semantics to be a power-set
semantics: the value of an expression is all possible results from all
possible glitchy interleavings of all sub-expressions. I wouldn't
want to program in that world. Maybe you do; the answer lies in the
semantics of your library.

What is that semantics? If you haven't written one down, no matter:
it's implicit in your programs. I am willing to bet your and your
users' source programs do NOT assume a power-set semantics, i.e., I
will not find a large number of conditionals checking for and skipping
over the "glitchy" answers as opposed to the normal one.

An amusing side question is how you will even determine the "correct",
non-glitchy answer. The only ways to do that are to repeat the entire
computation redundantly, or to tag every value with whether or not
it's glitchy. Does your library do either of those? If not, again,
you've assumed glitch-free execution.

Shriram

[Christopher Meiklejohn]

On Sunday, December 2, 2012 2:33:50 PM UTC-5, Shriram Krishnamurthi wrote:

I'm happy to hear arguments to the contrary, but:

> However, I do not believe it's correct in saying it's not FRP
> because of it's "glitchiness", as this property is not an essential
> property of functional reactive programming.

That's bunk.

The problem with glitches is this: you can obtain a value from the
program that is inconsistent with its semantics (which, in a
transparent FRP language like FrTime or compiled Flapjax, is defined
in terms of the base language).  This makes any non-trivial static
reasoning about the program essentially impossible.  You can't perform
substitutions, establish invariants, etc., and if you do, you would be
reasoning faultily.  I cannot think of anything more antithetical to
FRP than that.

My apologies, I didn't express myself correctly in my previous email.

The library I'm working on now currently implements depth-first evaluation, and

I'm completely aware of the problems which that poses with glitches, as outlined 

in both of Flapjax papers.  I'm in absolute agreement with you.

I didn't mean to come across as if I'm arguing that "glitchiness" is desirable or 

acceptable property in a FRP system.  My choice in wording was poor.  

My library is still in development, as stated on the GitHub page, and this is

something that I'm going to be implementing.

- Chris

[Shriram Krishnamurthi]

Fair enough. That's great to hear.

It will be interesting to see what difference it makes where you put
the FRP: at the source, pre-compilation level (as you seem to be
doing) versus at the target level (as Micha is advocating). Do report
back to the list!

Shriram