yanatan16 / fyra

Experimental framework based on Functional Relational (not Reactive!) Programming
MIT License
30 stars 3 forks source link

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:

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

License

See LICENSE file.