Re: Syntax of transitions

Frank Ellermann <nobody@xyzzy.claranet.de> Sun, 21 January 2007 05:16 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8V3g-0006G0-G2; Sun, 21 Jan 2007 00:16:00 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8V3f-0006Fj-4j for cosmogol@ietf.org; Sun, 21 Jan 2007 00:15:59 -0500
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8V3c-0002d4-LG for cosmogol@ietf.org; Sun, 21 Jan 2007 00:15:59 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H8V3Q-0007AG-Lu for cosmogol@ietf.org; Sun, 21 Jan 2007 06:15:44 +0100
Received: from 212.82.251.18 ([212.82.251.18]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <cosmogol@ietf.org>; Sun, 21 Jan 2007 06:15:44 +0100
Received: from nobody by 212.82.251.18 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <cosmogol@ietf.org>; Sun, 21 Jan 2007 06:15:44 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: cosmogol@ietf.org
From: Frank Ellermann <nobody@xyzzy.claranet.de>
Date: Sun, 21 Jan 2007 06:13:17 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 80
Message-ID: <45B2F66D.402F@xyzzy.claranet.de>
References: <20070108162900.GA66689@finch-staff-1.thus.net> <20070109221042.GC28340@sources.org> <45A56A51.2874@xyzzy.claranet.de> <20070111145057.GE24072@finch-staff-1.thus.net> <45A69776.2653@xyzzy.claranet.de> <20070112073817.GB44116@finch-staff-1.thus.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: 212.82.251.18
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 1.8 (+)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Subject: Re: Syntax of transitions
X-BeenThere: cosmogol@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: DIscussion on state machine specification in IETF protocols <cosmogol.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/cosmogol>, <mailto:cosmogol-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/cosmogol>
List-Post: <mailto:cosmogol@ietf.org>
List-Help: <mailto:cosmogol-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cosmogol>, <mailto:cosmogol-request@ietf.org?subject=subscribe>
Errors-To: cosmogol-bounces@ietf.org

Clive D.W. Feather wrote:
 
>> 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 ;

Yes, but that's starting to be less readable if you're looking
for "what can happen in a given state", or "what's the effect
of a given message in any state".

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

LOL.  My main example is a CharmapML UTF-8 "validity" state
machine, and for that purpose you might change your mind, the
"messages" there are 256 octets.

We could also try to encode the I-D tracker state machine as
an example / exercise.

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

In this thread I first tried to use a variant of states + messages,
but then I saw a messages @ states in one of your articles, and 
immediately decided that this is clearer.

Normally you have a directed graph with states as nodes, and some
messages on the edges connecting nodes, for that it's more natural
to use states + messages.  But of course messages @ states is
equivalent, and the "@" is unambiguous, while a "x + y" is often
(excl. floating point numbers) the same as "y + x", but not here.

Therefore I'd opt to eliminate states + messages in favour of "@".

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

If you pick single message @ states, not a list or set of messages,
then you could sort the expanded version by the messages.  That has
a similar effect, and it's clearer than grouping.  

Therefore I'd opt to eliminate this grouping.  There won't be many
opportunities where that's still readable in RFCs, and if it's to
some degree readable, than an expanded version is also readable.

> (3) Use of lists versus sets.

Maybe we could make lists and sets more obvious with parentheses:

Instead of   M1, M2, M3 @ Sa, Sb -> Sc : AI, AII ;
it would be  (M1, M2, M3) @ (Sa, Sb) -> Sc : (AI, AII) ; 

For named sets SoM, SoS, and SoA we could demand that they can
be only used within a list, e.g.

(M1, M2, SoM) @ (SoS) -> Sc : (AI, SoA)

In other words anything outside of parentheses must be a single
message, state, or action, it can't be a list or named set.  

Frank



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