Applicative Programming with Effects
Conor McBride and Ross Paterson.

Applicative Functors and Traversable.

www.staff.city.ac.uk/~ross/papers...

Monads for functional programming
Philip Wadler

"Monads provide a convenient framework for simulating effects found in other languages, such as global state, exception handling, output, or non-determinism. "
homepages.inf.ed.ac.uk/wadler/paper...

The Standard Template Library
Alexander Stepanov
Meng Lee
The paper that added iterators, algorithms, containers to the standard library.

www.stepanovpapers.com/STL/DOC.PDF

I think it's a non-issue: Switching to this style solves the interop problem for my compile time type system, yet if I need facades that are C++ type distinct I can always inherit into differentiable *instances*. Best of both worlds.

It’s why I’m excited for initiatives like what’s being undertaken at @socarxiv.bsky.social

We need to rethink the submission pipeline, close the cracks, and raise the bar. Knowledge production & dissemination is our species’ holy grail of progress and we can’t lose it to slop

That's it. That's the paradigm.

It's incredibly self-similar and composable, which makes for clean maintainable code, but also powerful and expressive code. I just have to negotiate the exact lenses I want to build for my library, but a lot of that is already figured out.

Thanks!

10/10

Finally, we might also want to extend facades. This is done with the same lens inheritance closure sub-paradigm used to construct models from kernels (stated previously). In particular with the concord class, this is exactly what I'm doing to represent local records within the concord.

9/10

What's more, each model ~ facade has specific methods ("equip") which allows us to temporarily equip the given class with lenses. The lenses inherit from the facade.

This is why the new paradigm is a refinement of the original: The paradigm is still embedded within it.

8/10

We add lenses to the model and inherit that class permanently in the definition of the container. We similarly build a literal for the given container from its facade.

This constructive paradigm is shared between all three containers { array, vector, concord }.

7/10

We do the same with the trace. Because the trace otherwise has the same memory components, we use the exact same lenses we used with the kernel but instead build the container's facade.

Next, we can build the container itself the same way we built the model from the kernel:

6/10

only (reusable) methods.

So to construct any given container, we start with its kernel and add to it a minimum amount of lenses (methods) through inheritance and close that off permanently by defining the container's model to inherit the kernel + lenses.

5/10

Keep in mind this means traces and all classes derived from them can only be temporary objects in a compile time context.

Continuing, the arrows in the graphic represent lenses: classes which assume a base class through inheritance (as template parameter), and never contain memory themselves,

4/10

with a vector, it's a C++ array along with a size_type value keeping track of the current size. A concord kernel is the same as a vector.

Anyway, for each kernel you have a corresponding trace, which has the same memory components except you replace the C++ array with a pointer + length.

3/10