> > John Volan said
> >
> > <<If the structure were available in the language, of course there would
> > be no question of using gotos for the same purpose.  Barring that, gotos
> > can be used to _simulate_ this structure, but this will always be a
> > dangerous practice, because the gotos are only at best a simulation of
> > the actual construct the programmer has in mind.  Gotos lack
> > "robustness"; certain important properties of the hypothetical structure
> > (e.g., prevention of "fall-through" between states in an FSA) cannot be
> > guaranteed except by programmer vigilance.
> > >>

> Robert Dewar wrote:
> >
> > First, to me, the mapping of states into sections of code, and the mapping
> > of transitions as gotos, seems pretty direct -- direct enough that I do not
> > think it would make sense to dream up some syntactic gizmo -- although as
> > Robert Eachus points out, a preprocessor can very well provide the equivalent
> > of this syntactic gizmo.

I would not suggest inventing an entirely distinct syntactic gizmo for
Ada (or any similar language), simply because there would not be a
sufficient number of applications to warrant the added complexity in the
language.

Karel Th�nissen wrote:
> 
> A gizmo like this:
> 
> gizmo State : (one, two, three);
>    -- the state variable is private to the gizmo (like loop indices)
>    -- the state variable is read-only, but can change (like loop
> indices)
>    initialStuff;
>    transit one;
> state one;
>    blaBlaTalk;
>    transit ....;
> state two;
>    smallTalk; -- use State as a read-only variable like a loop index
>    transit ....;
> state three;
>    fileBusterTalk;
>    terminate; -- or something of that kind; needs more braincells spent
> end gizmo;

How about this instead:

  type State_Type is (One, Two, Three);
  State : State_Type := State_Type'First;
  ...

  FSA_Name:
  loop
    case State is
    when One =>
      ...
      if ... then
        State := ...
      elsif ... then
        State := ...
      else
        State := ...
      end if;

    when Two =>
      ...

    when Three =>
      ...

    end case;
  end loop FSA_Name;

i.e., exactly the loop+case idea, but with the following addition:

  pragma Finite_State_Automaton (FSA_Name, State);

This pragma would enforce the following criteria: (1) FSA_Name must be
the name of a loop. (2) The loop must contain only a case statement. (3)
The controlling expression of this case statement must be the State
variable given in the pragma. (4) Every when-clause in the case
statement must end with an explicit assignment of the State variable to
some value, or with a named exit from the loop. (4a) If a given
transition is from one state to the same state, this still must be
explicitly expressed with an assignment statement.  (4b) If there is
more than one possible transition from a given state, requiring
conditional code to discriminate the different possibilities, then each
branch of the conditional logic must end with an explicit assignment of
the State variable (or loop exit).

The advantage of using a pragma for this rather than a new syntax is
that it doesn't require any actual change in the language definition.
Instead, it just layers some special-case semantics on the existing
syntax of the language, which seems quite appropriate for this special
case situation.

I suppose a similar sort of pragma might be devised for the code+goto
style, requiring that every conditional branch within a given code-block
end with an explicit goto.

But again, it's hardly worth the effort to design and implement such a
pragma, given the low demand for FSAs in most software. 

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name       => "John G. Volan",
   Employer   => "Texas Instruments Advanced C3I Systems, San Jose, CA",
   Work_Email => "jvolan@ti.com",
   Home_Email => "johnvolan@sprintmail.com",
   Slogan     => "Ada95: World's *FIRST* International-Standard OOPL",
   Disclaimer => "My employer never defined these opinions, so using" & 
                 "them would be totally erroneous ... or is that"     &
                 "just nondeterministic behavior now? :-) ");
------------------------------------------------------------------------