From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,a3ca574fc2007430
X-Google-Attributes: gid103376,public
From: mazzanti@iei.pi.cnr.it (Franco Mazzanti)
Subject: Re: Ada and Automotive Industry
Date: 1996/12/10
Message-ID: <mazzanti-1012961020560001@131.114.200.115>#1/1
X-Deja-AN: 203294266
organization: IEI-CNR
newsgroups: comp.lang.ada
Date: 1996-12-10T00:00:00+00:00
List-Id: <comp.lang.ada>


Robert said:

> Franco said
> 
> "For Ada95, the numbering of "Ada Items" has clealry restarted from 1, but
> it is not clear how many of the unresolved Ada 83 items would be
> still applicable to Ada95  (hopefully a small number, but definitively a
> number greater than zero)."
> 
> What makes you think this? Part of the design work on Ada 95 required
> careful consideration of every Ada 83 AI (rememebvr that there are 
> nowhere near 1500 real AI's, many of these are presentation issues,
> e.g. commas in the wrong type font).
> 
> If there is an Ada 83 AI that is not considered and dealt with in quite
> a deliberate manner in the Ada 95 RM, it is an oversight, and one that
> I would be surprised to find ...

I never said of 1500 AI.  I mentioned the number of 903 Ada83 AI's 
which is the number appearing in the ai-index.toc file at AdaIC.
I did not actually count the number of "real" AI's' which appear in the
Ada83-comments directory.  
In effect, if we count them, we see that the "real" AI are just 591, and
of these 53 are "confirmations". So, we are left with just 538 "real"
AI's.  That's not bad.

--------

I do know if it is oversight, of if there is some kind of deliberate 
(undocumented) decision behind this, but there are that some uncertainites
which were mentioned in Ada83 commentaries, which seem to be still
unresolved in Ada95.

For Example, let us consider the issue of "file objects" and parameter
passing modes (this problem was raised in ai-00828).
While the parameter passing modes for objects type File_Type are well
defined by the RM (they are those required by the full type definition),
it is still very uncertain the effect that the "passing mode" is allowed
to have with respect the the associated "file object".
E.g in the following case:

 My_File: File_Type;
 ...
 procedure Foo(F: File_Type) is 
 begin
   ...
 end Foo;

 Foo(My_File);

Should the activity of Foo work with the same "file object" as that
which is associated to the variable "My_File", or can Foo work on a
"file object" which is a "copy" (?) of the file object associated with
My_File (and what could this mean)?

(Notice that "file objects" and objects are type File_Type are different
concepts)

 This uncertainty is well reflected e.g. by GNAT v.3.07, according to
which "file objects" do not look as if they were passed by copy, nor by
reference, but in a third way which could be called "half and half" :-)
as shown by the following simple program.

with Ada.Text_IO; use Ada.Text_IO;
procedure main is
   F: File_Type;
   procedure foo (FF: File_Type) is
   begin
      -- For the lawyer: File_Type is an access type and IS passed by copy
      -- It is not a bounded error to use both F and FF
      --
      Put_line(FF,"first_line");
      if Line(F) = 2 then
         Put_Line ("It seems that F and FF denote the same file object");
      end if;
      Close (F);
      if Is_Open (FF) then
         Put_Line ("It seems that F and FF denote different file objects");
      end if;
   end foo;
begin
   Create (F, Out_File,"newfile");
   foo(F);
end ; 

-----------

Another minor uncertainty which has been left "untouched" is that one
mentioned in AI-00587 (but that is a minor point).

-----------

Franco