Statefulness = "Processness"...?

[Chris Pressey]

Jay Nelson wrote:
> When I mentioned Okasaki's term "persistence" it means
> something very different than the same term applied to
> OO instances.

I understood that much, or at least I thought I did.
I think I accidentally swapped the meaning of the terms, though.
(I hate terminology.  It's really unfortunate that I can idly say
"single-assignment variable" and most programmers won't even blink.)

> [...]
> First note that paying attention to the internals without regard
> to the display leads to an efficient and understandable data
> structure that is completely unexpected when compared to the
> imperative approach used by X-windows, et al.

Absolutely.  The condition is a lot worse in something like Visual
Basic, which encourages a bizarre "front-in" design philosophy.

> Second, the code uses the nature of functional data structure
> versions that comes automatically to allow undo and redo.
> [...]
> To do this in an imperative language you would have to introduce
> lists and explicitly copy the string every time (and I'll bet you
> wouldn't have stored it backwards because you probably pre-
> allocated the memory and used a pointer -- it wouldn't even occur
> to you that backwards storage might be beneficial)

Actually, this is mainly where my confusion was.  In an imperative
language, I don't think it's that much more complicated - I'd just
use a stack for undo.  A stack being a 'naturally backwards' list.

My idea of the implicit 'undo' in a functional language results
from the recursion itself, and doesn't require a list - the best
example I can think of right now is backtracking (which is
essentially a form of undo.)  The old values are 'remembered' in
the call stack (or whatever mechanism is used to do the recursion.)
So you just return from the current scope, and the previous
scope still has access to the data it was using before the call,
since it can't have been changed by anything else.  Undo, no lists
required.

The thing is, you can't do it this way with a textbox, essentially
because the textbox is shared.  Maybe you could do it this way
with a single textbox in a modal dialog box with one owner which is
patiently waiting for it to close and which isn't sharing it with
anything else.

But not in the general case.  Definately not, if we're considering
'liveness' as an important property (some other node might want the
textbox contents to change, etc.)

> so I would
> wager the imperative implementation would be less efficient.  On
> top of that you would have to make new instances with different
> length pre-allocated buffers for each textbox you wanted, or else
> make it really big and hope you never overrun it (probably the
> most commonly occurring and most insecure bug in all of software)
> or some complicated realloc refinement would have to be
> introduced (which of course would triple the memory use
> because you would realloc at double size, copy memory and
> then free).

Yeah, doing it without GC would suck.

> In erlang, manipulating every version of the data structure that
> ever existed is more natural and fairly straight-forward.  The
> textbox behaviour above could be in a separate process so no
> other code could get at the internals other than using the message
> interface (strong encapsulation). If a pointer to a particular
> version of the textbox internals were obtained outside the
> process, it couldn't be changed in a way that would affect the
> textbox or undo / redo.  Also you get concurrent execution with
> all the other textboxes (think of scrolling stock tickers for
> different stock market exchanges instead of text type-in boxes).
>
> In fact, other processes could arbitrarily ask for _any_ version
> of the textbox internals if you provided an message interface to
> do so.
>
> jay

I pretty much agree with this when it comes to controls with state,
like textboxes.

But what about controls without state, or barely any state, I
wonder?  Like pushbuttons and frames and labels.  Do they still get
processes?  If so, why, if it is wasteful enough to warrant not
doing it?  And if not, how do you deal with the unorthogonality
that will almost certainly present?

-Chris


______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca