After playing around with regular expressions in my rfc2822 project it was clear than I needed a different approach. I figured I'd give plain 'ol state-machines a go. I've now done so and the library is much cleaner and easier to debug because of it and my question is thus: I have, of course, made the state-machine bits an independent library. It is about 44K including documentation. Does it warrant its own project? It would be nice to get some speed-heads in on this and make sure it's as lean and mean as it can be.
Example run from example.lisp:
* (state-machine::zeros-and-ones "010102101" t) Current state: UNKNOWN-STATE Data: (010102101) Next state: WE-HAVE-A-ZERO Current state: WE-HAVE-A-ZERO Data: (10102101 . T) Next state: WE-HAVE-A-ONE Current state: WE-HAVE-A-ONE Data: (10102101 . T) Next state: WE-HAVE-A-ZERO Current state: WE-HAVE-A-ZERO Data: (0102101 . T) Next state: WE-HAVE-A-ONE Current state: WE-HAVE-A-ONE Data: (102101 . T) Next state: WE-HAVE-A-ZERO Current state: WE-HAVE-A-ZERO Data: (02101 . T) Next state: END-STATE Current state: END-STATE Data: (2101) Next state: NIL NIL *
Erik.
Erik Enge eenge@prium.net writes:
After playing around with regular expressions in my rfc2822 project it was clear than I needed a different approach. I figured I'd give plain 'ol state-machines a go. I've now done so and the library is much cleaner and easier to debug because of it and my question is thus: I have, of course, made the state-machine bits an independent library. It is about 44K including documentation. Does it warrant its own project?
That is hard to say. I don't really know. But I like the idea of having a large standard lib of smaller pieces from where you can take what you need - as long as this does not imply dependency hell. I don't know if that is possible, however.
It would be nice to get some speed-heads in on this and make sure it's as lean and mean as it can be.
Let it roar :)
Example run from example.lisp:
- (state-machine::zeros-and-ones "010102101" t)
Current state: UNKNOWN-STATE Data: (010102101) Next state: WE-HAVE-A-ZERO Current state: WE-HAVE-A-ZERO Data: (10102101 . T) Next state: WE-HAVE-A-ONE Current state: WE-HAVE-A-ONE Data: (10102101 . T) Next state: WE-HAVE-A-ZERO Current state: WE-HAVE-A-ZERO Data: (0102101 . T) Next state: WE-HAVE-A-ONE Current state: WE-HAVE-A-ONE Data: (102101 . T) Next state: WE-HAVE-A-ZERO Current state: WE-HAVE-A-ZERO Data: (02101 . T) Next state: END-STATE Current state: END-STATE Data: (2101) Next state: NIL NIL
Approved (bds/mit?)
regards, Mario.
On Mon, Nov 24, 2003 at 12:05:34PM -0500, Erik Enge wrote:
cleaner and easier to debug because of it and my question is thus: I have, of course, made the state-machine bits an independent library. It is about 44K including documentation. Does it warrant its own project?
I think a good state-machine library would be pretty neat thing, but as I mentioned to Erik on irc, I think in it's current form this is probably on the lower bound of separate-projectness.
So, approved with some reservations unless Erik is persuaded otherwise.
-
We really should come up with a heuristic for separate projectness. I tried to type one up off the cuff, but it's obviously too early in the morning. ;)
Cheers,
-- Nikodemus
On Mon, Nov 24, 2003 at 12:05:34PM -0500, Erik Enge wrote:
cleaner and easier to debug because of it and my question is thus: I have, of course, made the state-machine bits an independent library. It is about 44K including documentation. Does it warrant its own project?
I think a good state-machine library would be pretty neat thing, but as I mentioned to Erik on irc, I think in it's current form this is probably on the lower bound of separate-projectness.
So, approved with some reservations unless Erik is persuaded otherwise.
We really should come up with a heuristic for separate projectness.
Cheers,
-- Nikodemus
-
Erik Enge -
Mario Mommer -
Nikodemus Siivola