One think I think meander really differentiates on is being "obvious". By that I mean that it's fairly clear what most of the basic transforms are doing, without learning a complicated pattern matching language. That's not quite as true when you get to advanced features like memory vars.
I’m interested to know what it is about memory variables that make them less clear (apart from determinism related situations surrounding non inductive data).
@dennisa mostly I designed/am designing it for symbolic manipulation/computation, and model checking (future). Many things fit into those spaces but some more easily than others. It’s great in situations where data is well defined/structured such as interpreters (which are virtually everywhere ie. dispatch).
Just that they're all mutable and such.
Reductions tend to have that quality. Memory variables are basically a named reduction of a specific kind.
Yeah, I don't think we could do better. But they're definitely less clear than plain bindings.
Totally agree on plain bindings.
I haven’t fully explored the utility and properties of the “fold variable” concept yet because I haven’t gotten off the ground yet, but I anticipate that it will have similar clarity drawbacks. Still, I think in most of those cases where I have the option, I prefer the mild clarity trade off over some more rules.
Yeah. It's the best you can do to express this kind of thing in this model