[OFFTOPIC] Time varying FSMs

[Oleg Goldshmidt]

Shachar Shemesh <shachar at shemesh.biz> writes:

> Didn't you just describe a Turing machine?

I don't think so. No one said anything about having an infinite number
of states, for instance. There may or may not be a connection, so what?
A Turing machine is a theoretical construct, I thought the question was
about practical approaches to a problem. I don't even think the original
question has a connection to a Turing machine. All Omer asked (as far as
I understood) was how one would create a *finite* state machine that
could "grow" or "lose" a state at runtime.

I just thought of a typical FSM design where you specify the events the
states, and the transitions/reactions, and in the end you have a
"machine" class with a bunch of possible states one of which is current,
and transition/reaction methods accepting events as arguments that do
something and modify the current state. Even in the fanciest designs
I've seen so far the components of the design are statically defined:
you know all the states, events, and transitions at compile time, if you
wish (my experience has been mostly in C++, guilty).

This is why I thought of MOP that allows your program's objects to
modify other objects and themselves at runtime, and modify your class
hierarchy at runtime, too, since that is also an object. My intuition
tells me that this will allow you to take the typical FSM design and
start adding/removing/modifying states and transitions on the fly.

If I have accidentally stumbled upon a way to construct a Turing
machine, I don't know. I doubt it, at least because nothing has been
said about expanding memory indefinitely. But I have not thought about
it enough.

-- 
Oleg Goldshmidt | pub at goldshmidt.org