Re: BoF session in Prague "Formal State Machines"

[Fred Baker <fred at cisco.com>]

Having written parsers for table-described state machines, I beg to  
differ. Table-described state machines can in fact be machine- 
readable if they are designed to be. It's just another way to write  
the language.

In fact, I'll argue the flip side; SDL and compiler-compiler  
languages like YACC often fail to describe every possible input in  
every possible state. Rather, they tend to say things like "the  
receipt of this input in any other state is an error and should be  
handled in <this> way" - where the action might be "ignore the  
input", "fail, discard all accumulated state, and revert to initial  
conditions", or something else.

What is required for any state machine definition to be complete is  
that every input is described in every state, and should the input  
arrive, the resulting actions, side effects, and new state must be  
unambiguously defined. What is necessary for that to be parseable is  
that the description be understandable by an appropriately-written  
program. Now, you might not *like* to write programs that recognize  
ascii-art cells and find in them things like input names, new state  
names, conditionals, actions, and side-effects. You might prefer  
token parsers like lex. But those are matters of preference, not  
possibility.

On Feb 6, 2007, at 10:24 PM, Stephane Bortzmeyer wrote:
> On Tue, Feb 06, 2007 at 10:09:09AM +0100,
>  Hannes Tschofenig <Hannes.Tschofenig at gmx.net> wrote
>  a message of 53 lines which said:
>
> > Why should I re-write my documents to comply to a more formal state
> > machine description?
>
> Figures (wether in ASCII-art, in Unicode-art, in SVG, in GIF or
> whatever) and informal tables are impossible to analyze automatically
> (for instance to check if they are deterministic, or to translate them
> automatically to software like Ragel). That's the main problem I have
> with informal descriptions: you cannot process them by software and
> you have to check them manually.
>
> Being parsable by a program is the main aim of the future language.
>
> _______________________________________________
> Cosmogol mailing list
> Cosmogol at ietf.org
> https://www1.ietf.org/mailman/listinfo/cosmogol

_______________________________________________
Cosmogol mailing list
Cosmogol at ietf.org
https://www1.ietf.org/mailman/listinfo/cosmogol