marick

marick

TL;DR I’ve forked the Lens package, changed the API some, added new lens makers and – most importantly – added a ton of documentation. In a usable state, but more could be done. Should I? Let me know. lens2 | Hex

——

In functional languages without mutable data structures, this has long been a topic: “how do you deal with the problem of updating one little piece of data deep inside a big nested structure?" Access is the built-in solution.

Another type of solution – popularized originally in Haskell – was “lenses”. The original lens package had lousy documentation, a metaphor that didn’t actually work, and an API that… didn’t encourage readable code. This, for example, is from an introductory explanation.

   Foo <$> f a <*> f b <*> pure c

Alas, because “first mover advantage” is very much a thing in libraries, that particular approach to lenses (including API) spread to other languages.

This has long frustrated me, to the point where (until I gave up on PureScript) I was writing a book called Lenses for the Mere Mortal.

In the dynamic languages, lens-equivalents haven’t been as hard to learn (fewer persnickety types), but I do think they need more explanation than the typical library does. But they tend not to get that.

A while back, I decided I would make documentation pull requests, and even a tutorial, for the Elixir lens package I’ve been using. But I got carried away and made API changes and added lenses for MapSet and BiMap/BiMultiMap (because I’d written them for my own code, and why should people who also wanted to use them with lenses have to repeat that work?) See the Rationale for more, including “Why not use Access?” and “Why a new package?”

The end result was something that is backwards compatible – except for one class of functions – but too different from the original to be merged. So I forked it.

This was a pretty big digression from my main retirement activity. While it’s in a usable state (tutorial, expanded doc strings, working code – almost all of it Paweł Obrok’s original), it could use more work. But I don’t want to do it if no one cares. So, if you’re inclined, take a look and let me know if you care.

Thanks again to Paweł Obrok and also Jean-Philippe Cugnet (for TypedStructLens), whose code made this mostly a matter of documentation.

Showing Posts 1 to 2

nallwhy

nallwhy

Your tutorials are really great!
Thanks :slight_smile:

krishna_vaguelyright

krishna_vaguelyright

I never though this could be a problem. I would love to see codebases & their architectural decisions on how/why they arrived at such deeply nested structures.

— All posts loaded —

Where Next? Top

Trending in RFCs Top

Hedgehog-ai
Hello I would like feedback on an experimental neuroevolution (including substrate encoding) library called Bardo based on the amazing wo...
New
tallakt
Hi I was working on an old idea of a “Soft PLC” written on top of Elixir. It was too much work but with the advent of better AI I though...
New

Other Trending Topics Top

dominicletz
Hey there, I haven’t seen a list of useful Elixir specific skills for the popular AI tools yet so I’m starting one here with my first. ...
New
mudasobwa
I fully migrated to my own harness from Anthropic/Gemini and I think it’s time to share it. Welcome DSH, the DeepSeek Harness, fully writ...
New
KristerV
Hey. Is there anyone here who creates agents in their apps? Not talking about using agents, but creating them. I’m finding it pretty diff...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
webofbits
With AI doing more of the implementation work, I’ve been wondering how much coding I should deliberately keep doing myself. My main conc...
#ai
New
OndrejValenta
(I just needed to vent somewhere and LinkedIn is full of hope, or hype, I’m not sure which exactly) AI dream has many faces, but general...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews