begin quoting Bob La Quey as of Fri, Oct 26, 2007 at 12:05:42AM -0700: > On 10/25/07, Andrew Lentvorski <[EMAIL PROTECTED]> wrote: [snip] > > However, that doesn't work very well when creating a copy is expensive > > or when there really is just one single "thing" which needs to get > > passed around. > > > > See, Okasaki, "Purely Functional Data Structures"
I stalled out on that. I need to go through it again. > > So, functional approaches to state often trade "broken" for "so slow it > > might as well be broken". > > I do not get this. I see no reason why functions cannot push state > (or an entire collection of states) around as easily as they push anything > else around ... and obviously deterministically. State is really only useful when it *changes*. If you have a lot of state, and you don't want side-effects, then making a change can be expensive. Lots of tearing apart, copying, and rebuilding... Personally, I *like* the idea of passing around the state; it's just that when you also throw in a desire to avoid side-effects that I get uncomfortable with the tradeoff. > Thus state has only to be made explict. State(s) become part > of the i/o to functions. Not a bad thing IMHO. Isn't I/O by definition a side-effect? > State does not have to be a side effect. Nor should it be. Then it's going to be slow. To make it fast, I would think you'd have to change the hardware, and even then, I'm not so sure it would work well. -- What if we disposed of RAM and just used the cache? Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
