Dynamic record updates

I totally see where you’re coming from. I had a similar realization, the tools/applications/enhancements I attempt to make seem to take more time than the original task would have! But that doesn’t stop me from trying :wink:

Lately, instead of sinking 20 hours into some improvement that isn’t even guaranteed to help, I’ll just spend an hour or two. If I like what I come up with, I’ll give it a shot. Maybe it isn’t perfect, but I try to improve it over time. Maybe I hate it – I likely didn’t fully understand the problem. In that case, I’ll just do the task when I need to, but continue to think in the back of my mind how it could be automated, or how the boilerplate could be reduced. Hopefully in the future I come up with something better.


Bringing it back to this thread’s topic, I think we have identified a problem (boilerplate in some circumstances). I’d like to consider solutions before conceding to live with it! I think the simplest solution is a record updater syntax, to complement the record accessor syntax. (I know this has been suggested before, and even in this thread!)

-- accessor
.x : { a | x : b } -> b

-- updater
^x : b -> { a | x : b } -> { a | x : b }

Now, is that perfect? Does it even help? No idea. I wish I could test it! If I knew more Haskell, I’d fork the compiler and add it in. At least to see how it feels to use. (Maybe the arguments should be flipped? Maybe it should use a different symbol?)

Another problem I saw mentioned in this thread is the idea of wiring up, for example, form fields. Every field is tracked in the model, and updates need to come back and get set in the model. Very boilerplatey.

JavaScript, for example, has a lot of ways to deal repetitive code like this. You can pass around field names (ie object keys) as strings, and access fields on the fly (obj[keyName]). That allows you to store your fields in some kind of set or list, and dynamically access the correct one. Of course, JavaScript can’t do this in a type-safe way… can we do this in Elm? Well, I think @hecrj’s form API idea/proposal is a very good start (I recently used it in a project and found it prevents a lot of this type of boilerplate). But I feel like we can do something more at a language/syntax level.

I have a vague Idea in my mind that macros of some kind might help, but I’m not sure what that would look like… personally, I’m still mulling over possible solutions, nothing solid at this point.

I’m eager to see what else we can come up with :slight_smile:

2 Likes