Shachar Shemesh <shac...@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 | p...@goldshmidt.org _______________________________________________ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
