begin quoting Bob La Quey as of Fri, Oct 26, 2007 at 08:22:22AM -0700: > On 10/26/07, Stewart Stremler <[EMAIL PROTECTED]> wrote: > > 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.
Yes, that's what you do to "change" state without side-effects. You create a new item of state and pass it back. > > 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. You can't change the state you passed in (that would be a side-effect), so to create your new state, you have to create it. If your state is small, no worries. If your state is large, how do you create it? By dismantling the old state and creating a new state with most of the data you passed in, plus a little bit of new state. > > 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. That's what we're discussing. :) And actually I'm not averse to minimizing side-effects per se, only with the idea that it should be /enforced/. > > > 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. Point. > Here a function is an explicit deterministic mapping > between a set of input arguments and a set of output > arguments. Yup. My error. I twigged on "I/O" and kneejerked. Apologies. I/O to the *program* is a side-effect. And a very useful one. :) > > > 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? How do you make a change to a gigabyte of data without changing the data you were passed in? You copy it. Let's say you have a gigabyte of state. Passing in a pointer is fast, so you're not copying a gigabyte at a time, isn't slow... but when you change a byte of your state, you either change it in-place (fast, but is a side-effect) or you copy that gigabyte of state (slow, but no side-effects). What's the third option? You can copy, or not copy, or what? > > 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. I've come to trust my uncertainty. Think of it as my grain of salt. > 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. FP languages are those that generally emphasize immutable data structures, which are created by composable functions. All data needed by a function is explicitly provided to the function, at invocation time (which is what I like). Many FP languages allow selection of which function to invoke not only by the function name, but also by the values passed to the function. (The last bit I don't think should be part of the definition, but it's the most common annoying characteristic of FP languages.) > Then we may find neither of us understands FP ... or, well > you know what the alternatives are :) Heh. Yup. -- Mmmm. Salty. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
