Re: GOTO considered necessary (reworked)

[Karel Th�nissen <thoenissen@hello.nl>]

John G. Volan wrote:
> 
> 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.

I am not able to judge the frequence in sufficiently large sample of
code.

> How about this instead:
 
[snipped: standard loop+case implementation of FSM]

>   pragma Finite_State_Automaton (FSA_Name, State);
 
> This pragma would enforce the following criteria:
[snip on list of semantic constraints for the pragma]

These are the semantics I had in mind too.
 
> 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.

The nice thing is that the code will work even if your compiler does not
understand the particular pragma. At the expense of missing the
additional security of course.

However, we should be careful (in general) not to extend this kind of
reasoning to far, because then we end up with a language design in which
everything is handled by the simplest of all control structures (the
infamous goto) that does all the dirty work, monitored by a couple of
pragmas that check semantic constraints for particular patterns (loops,
selections, etc.). If they are supported, that is.
 
> 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.

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

Or is that because FSM's are avoided because people do not recognize
them or fear the goto-based programming that is implied? FSM's have more
applications than lexical analysis alone: communication protocols,
process description in discrete simulation, user interface interaction
at various levels, games, control tasks in operating systems, ...

Groeten, Karel