Re: BoF session in Prague "Formal State Machines"

Fred Baker <fred@cisco.com> Thu, 08 February 2007 07:21 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF3ax-0007X7-I2; Thu, 08 Feb 2007 02:21:27 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF3aw-0007Wz-Gc for cosmogol@ietf.org; Thu, 08 Feb 2007 02:21:26 -0500
Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF3at-0001VP-Ol for cosmogol@ietf.org; Thu, 08 Feb 2007 02:21:26 -0500
Received: from ind-dkim-1.cisco.com ([64.104.140.57]) by ind-iport-1.cisco.com with ESMTP; 08 Feb 2007 12:18:37 -0800
X-IronPort-AV: i="4.13,299,1167638400"; d="scan'208"; a="75241501:sNHT68797512"
Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by ind-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l187LKcG030779; Thu, 8 Feb 2007 12:51:20 +0530
Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l187LIU3009382; Thu, 8 Feb 2007 15:21:19 +0800 (CST)
Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Feb 2007 15:21:16 +0800
Received: from [10.0.0.96] ([10.70.230.36]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Feb 2007 15:21:16 +0800
In-Reply-To: <20070206212438.GA23042@sources.org>
References: <20070205202703.GB1731@sources.org> <45C845B5.7050201@gmx.net> <20070206212438.GA23042@sources.org>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <71C245A9-A53C-4E44-B944-55381FBFA8E7@cisco.com>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Date: Thu, 8 Feb 2007 00:24:19 +0100
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 08 Feb 2007 07:21:17.0318 (UTC) FILETIME=[B9189A60:01C74B51]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2232; t=1170919280; x=1171783280; c=relaxed/simple; s=inddkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20<fred@cisco.com> |Subject:=20Re=3A=20BoF=20session=20in=20Prague=20=22Formal=20State=20Mac hines=22 |Sender:=20; bh=Dy3dhMN5WQSnUlgzrAJZOeAJihxqRwas/2vpKnLcwCY=; b=flLXuILcBaBnzxVrsml2LtsuRFRf7dZ2yMaBLHejIej6hPcQnuLahxzA6DvpR5PYbdCLMfYc 2PM401qC4jGRssSl7EnkdM6DZ8YdnQWNdkAKYQkgjfcKVkd3v34TjIAp;
Authentication-Results: ind-dkim-1; header.From=fred@cisco.com; dkim=pass (s ig from cisco.com/inddkim1002 verified; );
X-Spam-Score: 0.2 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: cosmogol@ietf.org
Subject: Re: BoF session in Prague "Formal State Machines"
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

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@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@ietf.org
> https://www1.ietf.org/mailman/listinfo/cosmogol

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