> > Apparently my ideas of an AFSM compiler is closer to the
> > table-driven compilers ?
>
Jürgen Kahrs wrote:
> I wouldnt say it this way. I was only surprised
> that you would prefer the data-driven style.
If you've got a framework that can implement an AFSM,
almost as simply as a spreadsheeet then you can experiment with
all kinds of utilities, like non-perfect translation from C-source to
pascal-family-source.
Perhaps such an AFSM *can* more easily be implemented in
an existing spreadsheet ?!
> A data-driven implementation in canonic AWK may
> look like this:
>
> BEGIN { state = "" }
>
> state == "" && /IF/ { state = "IF" ; Encode(...) }
> state == "IF" && /ELSE/ { state = "ELSE" ; Encode(...) }
OK, does this mean:
IF (Presentstate=nil) & (NextToken="if")
THEN "IF" -> Presentstate; Encode(...) END
??
You see it's almost as verbose as my pseudo-code.
I prefer a data-driven approach, because it hides irrelevant information
better. If you're stepping through a FSM-diagram you don't need to
ask "what is the PresentState" because this info. is known, contained
in the like-program-counter.
IMO the whole idea of using a FSM approach is to hide the confusing
and irrelevant implementation details so that you can concentrate
on the 'data'.
Thanks for feeedback,
== Chris Glur.
