!standard 01.01.03 (15) 98-10-08 AI95-00119/02 !class ramification 98-05-05 !class confirmation 96-04-04 !status ARG Approved 98-10-08 (Via previous vote) !status work item (revised by Ted Baker, per action from St. Louis meeting) 98-05-05 !status ARG Approved (with changes) 9-2-0 95-11-01 !status work item 96-04-04 !status received 96-04-04 !priority Low !difficulty Hard !subject Is Normal Termination an "External Interaction"? !summary 98-04-01 Termination of a program is considered an external interaction. !question 96-04-04 Is the normal termination of a program with no function result or parameters an external interaction? It isn't defined as one in paragraphs 9..14 of RM95-1.1.3. In particular, the following main program has no external interactions as defined in 1.1.3: procedure Main is begin loop null; end loop; end Main; May an implementation optimize out the infinite loop? The resulting program also has no external interactions; the only difference is that it terminates. !response 98-04-01 RM95-1.1.3 (12) includes as an external interaction: Any result returned or exception propagated from a main subprogram (see 10.2) or an exported subprogram (see Annex B) to an external caller. RM 10.2 (2) says that a main subprogram "can be invoked from outside the Ada implementation". RM A.15 goes on to describe the possible interactions of a main subprogram with the "external execution environment", including the possibility that a main subprogram may return a status value. In particular "Normal termination of a program returns as the exit status ... ". The above language must be understood as an attempt to define in Ada terminology ("invoked", "result returned", and "exception propagated") interactions with an external execution environment that is not itself governed by the ARM. The ARM does not (and cannot) define the exact manner of invocation of a main subprogram by the external execution environment, how parameters may be passed to it (if any), how the main program may return status, or what activities in the external environment may be triggered by termination of the main program (whether normal or abnormal). Therefore, unless a given implementation can determine that a specific external environment will not be affected by whether a given program terminates, the Ada implementation must assume that it might. Even within the Ada domain, elimination of an infinite loop from a subprogram is not an acceptable optimization. For example, consider the following: procedure External_Environment is procedure Main is begin loop null; end loop; end Main; begin Main; Explode_The_Bomb; end External_Environment; No one would argue that it would acceptable to delete the infinite loop above, assuming that Explode_The_Bomb has some "external interaction" as the name suggests. By analogy, there is no reason to presume that the external environment from which an Ada program is invoked is not capable of expressing a dependence such as the one above. !appendix 96-04-04 !section 1.1.3(15) !subject External interactions !reference RM95-1.1.3(15) !from Keith Thompson 95-11-30 !reference 95-5400.a Keith Thompson 95-11-30>> Is the normal termination of a main program with no function result or parameters an external interaction? It isn't defined as one in paragraphs 9..14 of RM95-1.1.3. In particular, the following main program has no external interactions as defined in 1.1.3: procedure Main is begin loop null; end loop; end Main; May an implementation optimize out the infinite loop? The resulting program also has no external interactions; the only difference is that it terminates. (This question was inspired by an article, , posted to comp.std.c by Dan Pop.) **************************************************************** !section 1.1.3(15) !subject External interactions !reference RM95-1.1.3(15) !reference 95-5400.a Keith Thompson 95-11-30 !from Bob Duff !reference 95-5405.a Robert A Duff 95-12-1>> > Is the normal termination of a main program with no function result or > parameters an external interaction? It isn't defined as one in paragraphs > 9..14 of RM95-1.1.3. > > In particular, the following main program has no external interactions > as defined in 1.1.3: > > procedure Main is > begin > loop > null; > end loop; > end Main; > > May an implementation optimize out the infinite loop? I suppose so. >... The resulting > program also has no external interactions; the only difference is that > it terminates. > > (This question was inspired by an article, , > posted to comp.std.c by Dan Pop.) - Bob **************************************************************** !section 1.1.3(15) !subject External interactions !reference RM95-1.1.3(15) !reference 95-5400.a Keith Thompson 95-11-30 !reference as 95-5405.a Robert A Duff 95-12-1 !from Ted Baker 95-12-2 !reference 95-5406.a Ted Baker 95-12-2>> | > In particular, the following main program has no external interactions | > as defined in 1.1.3: | > | > procedure Main is | > begin | > loop | > null; | > end loop; | > end Main; Whoa!! How about 1.1.3 (12)? This procedure never returns. A subprogram conveys information to the caller by whether it returns or not. (Aside: Anybody who has studied automata theory should remember that this is the way acceptance of a set by is defined for Turing Machines: A string that causes the TM to cycle infinitely is considered to be "rejected".) "Optimizing away" the loop so that the program returns would change the external effect. --Ted Baker **************************************************************** !section 1.1.3(15) !subject External interactions !reference RM95-1.1.3(15) !reference 95-5400.a Keith Thompson 95-11-30 !reference 95-5405.a Robert A Duff 95-12-1 !reference 95-5406.a Ted Baker 95-12-2 !reference RM95-10.2 !reference 95-5408.a Keith Thompson 95-12-4 !from Ted Baker 95-12-05 !reference 95-5410.a Ted Baker 95-12-5>> Keith says: | A parameterless main program doesn't return any result. ... | The problem is that the RM's definition of | "external interactions" does not include the normal termination of a | parameterless procedure main program. In my opinion, it should. I am arguing that the basis already exists in the RM for the interpretation which you have in mind. Where does the RM define "result returned" from a main subprogram? Certainly, in a UNIX environment at least, every main subprogram DOES return a result (status), even if in the Ada view we don't see any value returned. Moreover, where is it written that the "result returned" from a main subprogram is a value? Returning control to the environment task, is a "result returned". --Ted Baker **************************************************************** !section 1.1.3(15) !subject External interactions !reference RM95-1.1.3(15) !reference 95-5400.a Keith Thompson 95-11-30 !reference 95-5405.a Robert A Duff 95-12-1 !reference 95-5406.a Ted Baker 95-12-2 !reference RM95-10.2 !reference 95-5408.a Keith Thompson 95-12-4 !reference 95-5411.a Erhard Ploedereder 95-12-6>> reference as 95-5410.a Ted Baker 95-12-5 !from Erhard Ploedereder !discussion This is beginning to sound like a discussion over how many angels fit on the tip of a pin. So far, the only difference apparent to me is between termination and non-termination of a partition that otherwise has no external interactions and possibly of a library task without external interactions. (I couldn't care less, if that is really the only difference.) What is the real concern here ? I don't think that anybody has argued that all endless loops can be optimized away, nor that local tasks that spinlock can terminate on the compiler's whim. **************************************************************** !section 1.1.3(15) !subject External interactions !reference RM95-1.1.3(15) !reference 95-5400.a Keith Thompson 95-11-30 !reference 95-5405.a Robert A Duff 95-12-1 !reference 95-5406.a Ted Baker 95-12-2 !reference RM95-10.2 !reference 95-5408.a Keith Thompson 95-12-4 !reference 95-5410.a Ted Baker 95-12-5 !reference 95-5411.a Erhard Ploedereder 95-12-05 !from Keith Thompson 95-12-06 !reference 95-5412.a Keith Thompson 95-12-6>> Ted Baker writes: > Where does the RM define "result returned" from a main subprogram? In AARM95-1.1.3(12.a): Discussion: By ``result returned'' we mean to include function results and values returned in [in] out parameters. I suppose the wording does allow for things other than function results and [in] out parameters, but I think the intent is that it includes only those things. The word "result" doesn't seem to be defined in the RM, but the usage in section 6 makes it clear that it refers to the value returned by a function. Hmm. Shouldn't a value passed to Ada.Command_Line.Set_Exit_Status also be considered a "result returned" from the main subprogram? > Certainly, in a UNIX environment at least, every main subprogram > DOES return a result (status), even if in the Ada view we don't > see any value returned. It's only the Ada view I'm talking about, though how to fit that into the UNIX (or other operating system) view is certainly relevant. > Moreover, where is it written that the "result returned" from a > main subprogram is a value? I think that calling normal termination a "result returned" is a bit of a stretch. A parameterless procedure doesn't return(v.t.) a result, it just returns(v.i.). I suspect we're in agreement that normal termination *should* be considered an external interaction; the issue is whether it's a ramification or a binding interpretation. Erhard Ploedereder writes: > This is beginning to sound like a discussion over how many angels fit on > the tip of a pin. No argument. Remember, I *like* debating obscure points. 8-)} > So far, the only difference apparent to me is between > termination and non-termination of a partition that otherwise has no > external interactions and possibly of a library task without external > interactions. [...] Almost. The partition (main program) could have had external interactions before entering the infinite loop. with ... procedure Main is begin Do_Some_Stuff; Put_Line("I'm going to sleep now...."); loop null; end loop; end Main; > What is the real concern here ? > I don't think that anybody has argued that all endless loops can be > optimized away, nor that local tasks that spinlock can terminate on the > compiler's whim. Agreed. I might have a legitimate reason to write something like the above (for example, in some environments I might want to keep a display window open that would otherwise vanish when the program terminates). If my compiler chooses to optimize out the idle loop at the end, what do I say in my bug report to the vendor? ****************************************************************