Re: Syntax of transitions

["Clive D.W. Feather" <[e-mail]>]

Frank Ellermann said:
>>> 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.

That depends. I agree that line lengths should be taken into account.

> 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.

Agreed.

> Maybe authors could write something like...
> 
> messageX1,
> messageABC @    state1,
>                 stateC-3,
>                 state46 ->      state47 :       action101,
>                                                 actionconnect;

or

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

> 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

No. Firstly because there may be other places where you want to do
actionconnect but not action101. Secondly because the comment will be in
the wrong place - it will be at the declaration and not at the place where
the action actually happens. And thirdly because it clutters up the
namespace and so harms the user's understanding.

>> 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.

I'm very happy to allow you to define sets that can be used in these
contexts, provided that I'm not forced to use them.

> 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.

I think we're in agreement then: sets available, lists available, state
machine author chooses what seems best in each situation.

> 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.

Agreed.

At present, the proposals that involve more than one way of doing things
are:

(1) "message @ state -> state" versus "state + message -> state"

(2) Grouping: "message @ (state -> state, state -> state)" versus expanding
it out.

(3) Use of lists versus sets.

All of these, I think, offer more benefit than risk of confusion.

-- 
Clive D.W. Feather  | Work:  <[e-mail]>   | Tel:    [phone]
Internet Expert     | Home:  <[e-mail]>  | Fax:    [phone]
Demon Internet      | WWW: http://www.davros.org | Mobile: [phone]
THUS plc            |                            |

_______________________________________________
Cosmogol mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/cosmogol