From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 2 Aug 93 17:47:39 GMT
From: seas.gwu.edu!mfeldman@uunet.uu.net  (Michael Feldman)
Subject: Re: Query about monitor (passive) task optimization
Message-ID: <1993Aug2.174739.16569@seas.gwu.edu>
List-Id: <comp.lang.ada>

In article <1993Aug2.064113.938@celsiustech.se> bjkae@celsiustech.se (Bjorn Kal
lberg) writes:
>
>I thought a Real Time program was a program, where timing was an essential
>part of the semantics. Thus, semantics is changed.

Certainly. And I argued that there are a lot of uses of tasking beyond
realtime, which have gotten short shrift from the Ada companies overall.
>
>>>From within the program, using only standard Ada, one wouldn't
>>even be able to detect whether the optimization had happened or not 
>>(this might be doable with CIFO-type interfaces, depending on the
>>runtime system implementation).  The only difference is that the program
>>runs faster.
>
>Or suddenly slower, when you change the program in some little way, so
>the compiler can not apply the optimization any longer, that it previously did
.
>And you do not get a warning or error, which you will if you have explicitly
>told the compiler, that this must be a passive task.
>
How does this differ from _any_ optimization? Do you want compiler-dependent
pragmas for every teeny little optimization? I doubt it.

>By the way, are not the automatic type conversions made by some programming
>languages, like PL1, quite wonderful? You don't have to write a lot of
>silly and unneccesary stuff. 

Different issue. These implicit conversions, which caused everyone so much
heartache, were part of the language design, not an implementer choice.
The passive-task thing is an IMPLEMENTATION-DEPENDENT PRAGMA. Or, in the
case of DDC-I, they just do it.

My objection was to some Ada users feeling that they need to control every
bit and microsecond of tasking. Why don't they insist on pragmas to
control every expression evaluation? I suspect it's because programmers
understand expressions and do not understand concurrency. And when they
don't understand something, they get antsy if they can't control it.

What Ada was supposed to be about was a common language for which the
validation process guaranteed most behavior. This was supposed to lead
to a very active and innovative compiler industry that would find lots
of neat ways of exploiting the language features, and lots of users
who would learn the features and trust their compilers.

So did it happen that way?

Mike Feldman