Flapjax Combinators: design basis, missing combinators, and connection with Backus function-level programming?
61 views
Skip to first unread message
Micha Niskin
Dec 2, 2012, 1:49:48 PM12/2/12
to fla...@googlegroups.com
Hi, I'm curious to know the design basis for the set of combinators in Flapjax. Flapjax provides an interesting, parallel evaluation model inside of JavaScript. It reminds me of John Backus' Function-level languages [1].
In FL there are three types of things: objects, functions, and combining forms. Objects are either primitive things (numbers, strings, etc.) or sequences of objects. Functions map objects to objects. Combining forms are higher-order functions which are provided by the environment at compile time. Combining forms are very similar (perhaps equivalent?) to Lisp macros. FL programs consist of a number of definitions, wherein the programmer uses objects, functions, and combining forms.
It seems to me that Flapjax provides the same. Combining forms (mapE, filterE, liftB, etc.) must be provided by the environment in order to participate in the pulse propagation system. Functions, likewise, are necessarily restricted to mapping objects to objects.
So my next research focus might be into some kind of unification of the two. Of course, my knowledge here is shallow, so I'd be very interested to know if you guys have already explored this or if I'm barking up the wrong tree?
While on the subject of combining forms, I've found the need for a "missing" combinator: the pipe. I didn't see any existing combinator that allows me to pipe events from an EventStream to a receiverE. This is a crippling omission because it makes abstraction and separation of concerns impossible. (Am I missing something?) For an example of what I mean, please consider my ClojureScript demo [2][3][4]. In this demo I create a sort of widget library where widgets are state machines. These state machines expose "gauges" (behaviors) that contain the current state of the widget, and "knobs" (event streams) by which events can be sent to the widget to cause a state change. Gauges and knobs are then connected using pipes to build more complex structures from simpler, independent ones. However, the lack of a piping combinator becomes an issue, as one must resort to writing code like this:
(mapE #(sendE (:selectE e) (nth % i)) linkedE)
Here I'm using mapE+sendE to do the required piping. This defeats the dependency graph, of course. There is no way for Flapjax to know that (:selectE e) depends on linkedE. I'm curious about the possible implications of adding a pipeE combinator, and would enjoy hearing what you guys think about it.
In FL there are three types of things: objects, functions, and combining forms. Objects are either primitive things (numbers, strings, etc.) or sequences of objects. Functions map objects to objects. Combining forms are higher-order functions which are provided by the environment at compile time. Combining forms are very similar (perhaps equivalent?) to Lisp macros. FL programs consist of a number of definitions, wherein the programmer uses objects, functions, and combining forms.
It seems to me that Flapjax provides the same. Combining forms (mapE, filterE, liftB, etc.) must be provided by the environment in order to participate in the pulse propagation system. Functions, likewise, are necessarily restricted to mapping objects to objects.
So my next research focus might be into some kind of unification of the two. Of course, my knowledge here is shallow, so I'd be very interested to know if you guys have already explored this or if I'm barking up the wrong tree?
While on the subject of combining forms, I've found the need for a "missing" combinator: the pipe. I didn't see any existing combinator that allows me to pipe events from an EventStream to a receiverE. This is a crippling omission because it makes abstraction and separation of concerns impossible. (Am I missing something?) For an example of what I mean, please consider my ClojureScript demo [2][3][4]. In this demo I create a sort of widget library where widgets are state machines. These state machines expose "gauges" (behaviors) that contain the current state of the widget, and "knobs" (event streams) by which events can be sent to the widget to cause a state change. Gauges and knobs are then connected using pipes to build more complex structures from simpler, independent ones. However, the lack of a piping combinator becomes an issue, as one must resort to writing code like this:
(mapE #(sendE (:selectE e) (nth % i)) linkedE)
Here I'm using mapE+sendE to do the required piping. This defeats the dependency graph, of course. There is no way for Flapjax to know that (:selectE e) depends on linkedE. I'm curious about the possible implications of adding a pipeE combinator, and would enjoy hearing what you guys think about it.
2. FJ CLJS Demo
Reply all
Reply to author
Forward
0 new messages