On 10/26/07, Stewart Stremler <[EMAIL PROTECTED]> wrote: > 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*.
A function can have a state variable as an input and that state variable as an output. So a function can change a state variable. > 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... Sorry. I just do not understand this. Further I do not think I agree. > 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. Uh duh. You and I are not communicating. I really do not see the need for side effects. I understand that they are used a lot in conventional programming. I just do not see why they _must_ be used nor what efficiencies they imply. > > 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? I am using I/O the function input and output arguments. Here a function is an explicit deterministic mapping between a set of input arguments and a set of output arguments. > > State does not have to be a side effect. Nor should it be. > > Then it's going to be slow. Unproved assertion. Why must it 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. I think your uncertainty are a poor basis for critiquing functional programming. But then maybe I do _not_ understand FP at all. Please tell me in a few short sentences how you define FP. If you do that for me I will do it for you. Then we may find neither of us understands FP ... or, well you know what the alternatives are :) BobLQ -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
