Statefulness = "Processness"...?

Jay Nelson <>
Thu Mar 13 05:27:21 CET 2003

Chris Pressey wrote:

 > I'd just use a stack for undo. A stack being a 'naturally
 > backwards' list.

A stack of strings?  Or a stack of character stacks?
The obvious would be a stack of strings, but every char
you add means a copy of the string plus one char to be
pushed on the stack.  With a stack of character stacks
you have to have a function that puts them together into
a string that you return when any version is requested.

Basically, anything you do needs a history of how this
state was arrived at either by retaining a copy of all the
states or by retaining a copy of all the edits performed.

 > My idea of the implicit 'undo' in a functional language
 > results from the recursion itself, and doesn't require a list

This is non-obvious to the style of programming I do.  It
has a few drawbacks, the main one being that you can't
manage the stack easily so you can't get back to a particular
version (e.g., imagine a text box with a pulldown that shows
every version of its state where you could select an older

You still need a list, when the stack is unwound the
chars have to be accumulated into a list (which may be
partially built at each recursive call).  The code and
exceptions get a little hairy.  It may require resorting to
a catch / throw pair, a less than elegant solution. Cut
of several characters in the middle of the string is
particularly difficult.  Typing in the data is not a recursive
or inductive act, it is an unpredictable serialized sequence.

It is much easier and clearer to use accumulator(s) in
the recursion and the accumulator(s) look(s) like the record
I used.

 > The thing is, you can't do it this way with a textbox,
 > essentially because the textbox is shared.

Unless your definition of textbox is radically different than
a standard one, it is by nature a single-state device.  If two
processes want to change it, there are either two instances,
two closures with two views, or last changed view only.  So
I don't understand this statement.


More information about the erlang-questions mailing list