Dualities in functional programming

The best practical understanding of Petricek's work I gained from using Clojurescript's Re-frame library. In re-frame, coeffects represent the data that an event handler needs from the outside world to do its job (like current time, random numbers, or local storage values). This aligns with the academic concept of tracking contextual dependencies, just applied practically in a front-end framework context.

The main difference is that re-frame uses a more pragmatic, simplified version focused specifically on event handling in web applications, rather than the full mathematical formalism of the academic work.

Learning re-frame was a light-bulb moment for me. I highly recommend giving it a try, even if there's never a plan to use Clojure or Clojurescript in practice.

The Erlang OTP handles the issue of data state reconciliation in a rather robust manner. However, this does not span all possible use-cases efficiently.

Have a great day =3

Things can have two dual dimensions, resulting in four concepts & four relationships.

Perhaps the fourth concept is “event” giving us:

Precondition <-> Postcondition, the relationship between a condition before & after a computation.

Event <-> side effect, the relationship between the environment activating a computational change, vs a computation activating an environment change.

Precondition <-> Event, the relationship of an environmental change, triggering a computational change.

Side effect <-> Post-condition, the relationship between a computational change, triggering an environmental change.

—-

If we think of the loop as both initiated and consumed by the environment, OR by the computation, we get dual loops through all four steps:

We have environment changes interpreted as an event by computation, which responds with an appropriate side effect, which in turn changes the environment. Environment to environment, through computation.

Or the loop can start with a side effect, causing an environmental change, whose event lets the computation react to the environments reaction to the initial side effect. Computation to computation, through envirinment.

that sounds very interesting

That looks like category theory rather than functional programming.

That author has a bit of a misunderstanding about Lisp:

"Lisp evaluation works by mutual recursion of eval and apply. Eval looks at an expression and if it is a function application it calls apply. Apply in turn calls eval on the arguments and invokes its function on them. This is call-by-value."

In classical Lisp and its descendants, apply is a function. Indeed, the paradigm is call by value, and therefore that function receives all of its arguments already evaluated.

When eval determines that its input form is a function call, it recurses first on eval to evaluate the argument expressions to a list of values. It then uses apply, which is a function which takes two arguments: the function to be applied, and a list object of values to be the arguments. apply doesn't do any evaluating, just the binding of the function to the arguments. eval needs this API, without which it has no way to pass a dynamically constructed argument list to a function.

It's not clear if there is a meaningful duality there; apply is a service required by eval. eval is not required by apply. apply can be written in terms of eval, but that eval cannot then use that apply. Also, it's mildly ugly, because apply has to carefully add quotes to the argument material to prevent eval from evaluating it again, so that just the desired effect is obtained of a function application and no other evaluations.