Re: RFC: Prototype for a user threading library in Ada

[rieachus@comcast.net]

On Saturday, June 25, 2016 at 3:11:57 AM UTC-4, Dmitry A. Kazakov wrote:
 
> The problem at hand is that parallel asynchronous code cannot be 
> designed in a reasonable way, at all. It is written it in a form of a 
> state machine, logically and technically *gotos*. It is the state of 
> software engineering of 70s wrapped in Ada constructs.

Um, I've always thought it funny that Ada state machines and Ada tasking mix nicely, and both need to be at the library level to work efficiently. I always used LALR on Multics which could handle LALR(k) grammars for any k, and even some non-LR grammars.  But it could also take a source file which mixed PL/I, C, Fortran, or Ada code with the grammar productions, and generate a (huge) source file which used a table driven engine.

If, and I understand it is a big if you could map the input to one or more independent sequential file, everything was wonderful.  However if you wanted to handle interacting inputs you were up a creek.  This limitation is not as bad as it sounds.  To take am aircraft radio, there would be several subsystems that could be handled separately. The interrupt causing events (from operator input) could be mixed into the data stream:  operating_state ::= (receiver_input) | (transmission) |(interrupt) (operating_state);

I can't imagine building a complex real-time system without a grammar tool and  Lui Sha & Goodenough real-time scheduling support tools.