🚀 go-pugleaf

"A. van Kessel" <imaavk> wrote:
>Can we please *STOP* this religious wars ?
>It is beginninning to look like YOUGOSLAVIA here ...

ME-GOSLAVIA?

>Ok, a last contribution to this amusing thread:

Yeah, right.

>I have a lot of small text-scanning programmes, implementing
>finite state automata but still to trivial to force me into 
>Yacc. The GOTO-less solution in my case ( ;-) ) is GOTO-less
>spagetti like:
[snip:GOTO-less solution]

>After jump-optimizing this reduces to something like:
[snip:GOTO-ful solution]

>WHICH IS BASICALLY THE SAME, BUT CONTAINS ONLY ONE LEVEL OF BRACES !!

SO WHAT!!  :-)

Seriously, here's a really good paper on the subject of the
implementation of finite state machines:

   Douglas W. Jones. _How (Not) to Code a Finite State Machine_,
   SIGPLAN Notices, vol. 23, no. 8, August 1988.

I couldn't find a copy online. It discusses the methods that you used
plus one or two others as well as the benefits of each. The "best"
solution (his terminology) that it presents does not explicitly
represent the state in a state variable--in effect, the PC is the
state variable and the logic is a direct implementation of those
"railroad" diagrams in which Pascal syntax used to be described. Oh,
yes, and there are no GOTOs.

This "best" method works as long as one doesn't need to maintain the
state between invokations. For example, I implemented a DFA that
recognizes C preprocessor tokens. The entire input stream is not
available at one time, so it must be called as needed. As a result,
because it needs to remember state between calls, I couldn't use this
solution.

-- 
Paul Long                            45:29:14N 122:48:09W
plong@perf.com                       http://www.teleport.com/~pciwww/
  "Where time or intelligence are lacking, a goto may do the job."
        - M.E. Hopkins, "A Case for the GOTO," 1972.