Re: Syntax of transitions

Clive D.W. Feather wrote:

>> you want the states written into lines with 69 characters.

> Non-sequitor.

The RFC line length is 72 minus 3 for the left margin.  It's
difficult to squeeze formal languages into these limits, and
if you fold longer lines the result can be hard to read.

But we want folks to read and understand state machines in
RFCs - if they'd be forced to extract the source and feed it
into some presentation tool it's a lost battle because no
casual reader or reviewer will do this.

Maybe authors could write something like...

messageX1,
messageABC @    state1,
                stateC-3,
                state46 ->      state47 :       action101,
                                                actionconnect;

...if messageX1 or messageABC in one the three listed states
cause action101 and actionconnect with next state state47.

But they could as well identify the corresponding action(s)
with a single name "do101", and mention the details in a
comment of the declaration:

actions:        foo,            # do the foo thing
                bar,            # do the bar stuff
                do101;          # signal 101 and connect

The actions in a state machine can be mere identifiers, what
it really means would be anyway in prose (comment or similar).

The states, the messages, and the next states are the core of
a state machine, the "actions" only connect this abstraction
with something real in a protocol.

> I want to be able to write:

>     Signal1 @ IDLE -> BUSY : "Send 101", connectSubscriber ;

> without having to invent a set just to contain these two actions.

Okay, for readability reasons I'd want to be able to define
and use a "do101" set of actions.  If it's in some "artwork"
(69 characters) of an RFC that could be better.

So I guess we need comma-separated lists of messages, actions,
and states (excl. next states after "->").

And maybe we need named sets as shorthands for such lists.  But
above all we need KISS, not a convoluted syntax with tons of
different ways to express the same idea.  It should be intuitive,
readers must get the point without ever looking into the manual.

Frank

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