Re: an infinate loop

[Matthias Kretschmer <m.kretschmer@bsdger.org>]

Ted Dennison wrote:

> So while I can't agree that "goto" inarguably makes this particular algorithm
> look better, it at least doesn't make it worse, and it performs it slightly
> quicker. I'm not sure that would normally be enough to justify its inclusion in
> the language. However, I'd observe that this issue comes up a lot more for
> compiler writers than for the rest of us, and compiler writers did create this
> language. :-)
>

Another way of implementing a state machine would be to make an array of subprogram
access types to subprograms handling the different states. This could be faster
than using case with using the current state as an index to the array. This should
be nearly as fast as using goto, just it doesn't use fixed jump-points. But if you
just implement features because of speed enhancements of special problems, than you
should implement everything including an assembler. Goto doesn't make it look
worse, but make it may be more complicated. Using for each state a seperate
subprogram would be probably make the whole stuff more appealing to the eyes of
other people.

But in the other hand, just use aflex or something like that for processing strings
and do not think about the implementation. As long as the aflex-programmers did
their job well, one do not have to worrie how it is implemented and how to change
the specific implementation, just using it is enough.

But this leads to another way of implementing a state machine. Using an approach
similar to aflex and the like. Implementing the statemachine with rules that apply
to different states and having just one subprogram processing the rules stored for
example in an array of records or something like that. The array can be filled at
run-time by processing a file (which could lead to the problem of using a state
machine for this parser :-)) or by a constant array hardcoded in the program.

mfg Matthias