immutable data structures are so frustrating to work with because instead of doing something like this:

data["foo"]["bar"]["baz"] += 1

you have to do this:

new_value = data["foo"]["bar"]["baz"] + 1

data = data.set("foo",
    data["foo"].set("bar",
        data["bar"].set("baz", new_value)
    )
)

currently running into this problem with Trickster and it’s :/

@kasdeya this is where i like shorthand accessors and lenses

const lens = path => target => // access target[path]

const over = (lens, transformation, target) => { /* calls transformation with the current value of target[lens] */ }

const inc = x => x + 1


over(lens('foo.bar.baz'), inc, data) 

(“functional lens” should be a searchable phrase if you’re interested, but effectively it’s a functional getter/setter)

@kasdeya this is when you build a better API to handle these boilerplate blemishes in your data structure. I hate writing inelegant code, but I also understand the benefits of immutability when it comes to idempotency and multi-threading. I'd rather build my API to better serve the human That's writing the code, while still allowing the actual implementation of that API to serve the application.

to make this even worse, what I’m trying to do is:

def set_variable(name, value):
    variables[thread_number][name] = value

which as far as I can tell wouldn’t have any concurrency problems if it were a data structure that I can mutate, but because I have to replace the entire data structure every time I change one value then I have to come up with some kind of thread safety system

@kasdeya ah, yep, as someone who's had to deal with thread safety issues in a professional setting, it's very annoying to deal with but even worse to have to fix.

@kasdeya I wrote my bachelor's thesis on optics. They are a handy approach to editing immutable data structures, especially the nested sort. This is the more technical Haskell library I used https://hackage.haskell.org/package/lens, while I also hear https://hackage.haskell.org/package/optics gets a lot of praise. I don't know if an implementation exists for Trickster though.

@rowan @kasdeya Ah, should have checked the replies before making my separate post. But +1 for optics either way!

@rowan @kasdeya oh! this unit notes similarities with swift keypaths! keypaths allow treating lambda x: x["foo"]["bar"]["baz"] as a single lookup instead of 3 nested ones; it effectively creates a ~field {the 'baz' key of the 'bar' key of the 'foo' key} that can be [accessed, modified] as if it was defined on the object itself. this unit is amused that lenses have escaped containment and jumped to imperative languages too :3c

@catgirl_so @kasdeya functional programming concepts will soon spread to all known and unknown languages and paradigms, corrupting them with its eldritch concepts such as The Lens and Transducers (as opposed to the cisducer )

mx @kasdeya, this one is so sad to tell you that this is one of the features that this one likes from Common Lisp. (setf (get-baz (get-bar (get-foo data))) new-value).

@kasdeya haskell gets around this with lenses which are honestly really nice

@kasdeya data & foo & bar %~ (+ 1)

@1 aww! that does sound like a great feature to have. Fennel had something similar and it confused me for a while but I was able to figure it out when working on my own Lisp language