3 ms·

Or you could just make a sequence of several stages itself be a stage, collapsing the preponderance of abstractions like this post talks about. Then, instead o

Or you could just make a sequence of several stages itself be a stage, collapsing the preponderance of abstractions like this post talks about. Then, instead of having a mutable property holding a directory, you might just use a function that takes a directory and returns a stage. You could have another function that takes a file and returns a stage. Guess what...this is starting to sound an awful lot like a monad. Departing a little from the OP's topic, I think it's interesting that your outlined design relies significantly on mutable state ("a property of type directory"). I think one of the biggest advantages of Haskell is its purity, which discourages you from thinking about things in terms of mutable state. This has far ranging positive effects. It makes APIs much easier to understand and use. That in turn results in Haskell programs having MUCH more code reuse than other languages.

twic 13y ago
> I think it's interesting that your outlined design relies significantly on mutable state ("a property of type directory"). The design does not rely on mutable state. The property doesn't have to be mutable. It doesn't even have to be a field - in an object-oriented language, it could be a method that collects the directories from the child steps. You appear to be dressing me in a strawman's outfit. > Then, instead of having a mutable property holding a directory, you might just use a function that takes a directory and returns a stage. You could have another function that takes a file and returns a stage. What? Could you expand on this? The thing i'd like to do would be to take a chain and make a list of the files in its various directories. How would i use your functions to do this?