From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_40,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,b45952e5dedb7e9a
X-Google-Attributes: gid103376,public
From: jm59@prism.gatech.edu (John M. Mills)
Subject: Re: State Machine Implementation
Date: 1998/08/06
Message-ID: <6qcr71$3hd@acmey.gatech.edu>#1/1
X-Deja-AN: 378580396
References: <35C90369.CFE8ED98@inficad.com> <6qcauo$ef4$1@nnrp1.dejanews.com>
Organization: Georgia Institute of Technology
Newsgroups: comp.lang.ada
Date: 1998-08-06T00:00:00+00:00
List-Id: <comp.lang.ada>


>In article <35C90369.CFE8ED98@inficad.com>,
>  "Ray A. Lopez" <rdsys@inficad.com> wrote:
>> Does anyone have any implementions of a state machine?  The states would
>> be just an enumerated type and I am guessing you would use a case
>> statement.  Just looking for more info on how to implement this using
>> Ada.

I would consider something like:

type Handlers is array(STATE) of access function(...) return STATE;

(give or take the grammar, sorry).  Each handler is associated with one
state.  Each handler performs what action it can, then determines if the
machine's state has changed, returning the appropriate new or old value 
of STATE, which is used as the call index on the next iteration.

Advantages: clean logic from outside the machine, and no massive case branch
or decision tree. State handlers are totally decoupled from one another.

Disadvantage: no externally obvious logic flow.

-- 
 John M. Mills, Senior Research Engineer   --   john.mills@gtri.gatech.edu
   Georgia Tech Research Institute, Georgia Tech, Atlanta, GA 30332-0834
        Phone contacts: 404.894.0151 (voice), 404.894.6258 (FAX)
           "Lies, Damned Lies, Statistics, and Simulations."