So if I'm understanding this correctly, you are generating a data structure describing geometry manipulations which can then be applied to a distinct geometry "instance?" If so, isn't this just a free monad?
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.
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'm not sure about how you would efficiently do this. (I'm not experienced with pure functional programming.) cloning the entire structure for every applied function sounds like it will be slow? is that not what you will have to do in practice?
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.
> cloning the entire structure for every applied function sounds like it will be slow? is that not what you will have to do in practice?
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 :)
Something doesnt necessarily have to be a free monad to be an internal dsl / interpreter. especially if you arent being strict about adhering to monadic rewrite laws.
"with-open-file" (skip to the examples) is a nice one since it takes care of opening and closing the file for you so you can write your block of code inside of it and be sure the file gets opened and closed properly:
(with-open-file (f "/path/to/file" :direction :output :if-exists :supersede)
... your code writing to "f" comes here ...
)
http://imgur.com/a/BoKdy
Repo at: https://github.com/inconvergent/differential-line