Experimental framework based on Functional Relational (not Reactive!) Programming
Clojure JavaScript HTML
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
example/real_estate start converting example Oct 28, 2015
phantom Convert tests to clojure.test Nov 28, 2015
resources/private/html Get cljs building. have to port off of midje to test in cljs Nov 24, 2015
src/fyra
test/fyra
.gitignore
.travis.yml
LICENSE First commit Oct 7, 2015
README.md update README Oct 29, 2015
project.clj Convert tests to clojure.test Nov 28, 2015

README.md

fyra

A clojure implementation of Functional Relational Programming as introduced by Marks and Moseley in Out of the Tar Pit.

TLDR This project is basically an experiment to see if adding the Relational model to modern clojurescript web programming can improve it.

Background

Work in Progress

This is in a very early stage, as I am learning how to implement a relational query engine as well as exploring the design strategies of Functional Relational Programming, as well as designing a new DSL in clojure (and the macro funkiness to go along).

Eventually, I'd like to see if this paradigm can scale out to web application design, where shared definitions of relvars and views allow a react-based front-end and an RDBMS-backed server to communicate efficiently and stay in sync. All with the hopefulness of avoiding the complexity of state management.

Functional Relational Programming (FRP')

Functional Relational Programming (FRP') is not to be confused with Functional Reactive Programming, which is a different paradigm.

FRP' was introduced in Out of the Tar Pit, which is worth the read if you think all software is broken. In the paper, the authors suggest this new paradigm for writing programs.

FRP' is basically the following:

  • A set of relations (relvars) which comprise the essential state of the system
  • A set of views (relvars derived using relational algebra) which comprise the way a system will look at its essential state
    • These views can use pure functions to arbitrarily modify the relational values
  • A set of feeders, which input and change data in the system (insert/update/delete)
  • A set of observers, which update output to other systems/the user upon change of a monitored relvar.
  • A set of performance and optimizing "hints" that have nothing to do with the outcomes of the system

Why I'm experimenting

After reading about this, I wondered how a system like this could fit with a react framework, such as reagent. Reagent already provides much of the "observer" mechanism by monitoring Reagent atoms for changes and updating components as necessary. Feeders can be in on-click handlers and the like.

But there are still issues lingering in modern clojurescript web apps, especially because state, whilst encouraged to be kept in one place, is still user managed and often stores more than it needs. Additionally, I have never encountered a server sync abstraction that didn't leak, but perhaps this project might lead me to one that won't (doubt it :/).

FRP' encourages separation of all these issues: core state, how the app interacts with state, actual parts that do interactions, and most importantly: how state is managed and stored.

So I think there might be something here. I'm probably wrong, because its been almost 10 years since the paper came out and I couldn't find any popular FRP' libraries. But who knows.

Documentation

Currently, you'll have to read some code.

Examples

The real estate example from the original paper is reproduced here.

TODO

  • enable the example
  • add api for storage hints
  • implementation for cljs/reagent
  • implementation for postgres

License

See LICENSE file.