Fork me on GitHub
#meander
<
2020-05-26
>
dominicm10:05:33

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.

noprompt17:05:40

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).

dominicm18:05:15

Just that they're all mutable and such.

noprompt20:05:43

Reductions tend to have that quality. Memory variables are basically a named reduction of a specific kind.

dominicm20:05:46

Yeah, I don't think we could do better. But they're definitely less clear than plain bindings.

noprompt20:05:52

Totally agree on plain bindings.

noprompt20:05:58

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.

dominicm20:05:27

Yeah. It's the best you can do to express this kind of thing in this model

noprompt17:05:39

@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).