Also, what are the advantages of this approach over simple function composition operating on immutable data structures/geometries?
not sure if there are any advantages. this is an experiment i'm working on because i find it interesting. separating the data structure from the instructions that attempt to manipulate it has the advantage of making it easier to deal with the state [the state is not changed inside (with-snek ...)]. basically it's a kind of map-reduce. i'm sure you can achieve this in multiple other ways as well.
one of the reasons i'm interested in this particular pattern is described further here: http://inconvergent.net/a-method-for-mistakes/.
What I meant is that it might be simpler to just have pure functions operating on immutable data structures, which you could then compose in whichever you want. I.e. you could have a function collapse-vertices that takes some geometry and produces some new geometry (without altering the initial one!), which you could then compose with some other pure function, like produce-random-vertices, and so on, much like a Unix pipe.
A free monad is just a formalization of the command/interpreter pattern in a purely functional context (i.e. most useful in languages like Haskell or Clojure).
i basically want the alterations to change the data structure, and i want them to do it according to a particular priority eventually. atm there is no priority ordering.
i can already make (almost) arbitrary functions, but you have to register them ahead of time, and they have to follow a particular pattern: http://inconvergent.net/arbitrary-alterations/. this is so that i can control the order in which they are applied, eventually.
In short, no - as an example, when an element is added to an immutable map, a big part of the newly produced map is structurally shared with the old one (check out [0].)
As for the ordering, you could have a list of geometry -> geometry functions. You could then take the initial geometry and apply the list of functions in order, or a permutation of it, or drop some functions, or apply some others multiple times, and so on.
But anyway, it's just an idea - thinking in terms of atomic geometry transformations instead of alternations may or may not be easier in more complex scenarios, I don't know :)
[0] http://hypirion.com/musings/understanding-persistent-vector-...