CVS difference for ais/ai-00204.txt

Differences between 1.4 and version 1.5
Log of other versions for file ais/ai-00204.txt

--- ais/ai-00204.txt	1999/02/03 19:10:09	1.4
+++ ais/ai-00204.txt	1999/02/08 23:00:58	1.5
@@ -94,7 +94,6 @@
 
 From:   Brashear, Phil
 Sent:   Friday, January 29, 1999 7:34 AM
-Subject:        Fortran support
 
 On tests CXB5004 and CXB5005, an implementation rejects the Import pragma
 because they do not define convention Fortran. As shown by CXB5001..3, they
@@ -115,7 +114,6 @@
 
 From:   Brukardt, Randy
 Sent:   Friday, January 29, 1999 1:33 PM
-Subject:        Re: Fortran support
 
 The discussion of AI-00204 at the Paris meeting suggests that such an
 implementation is not allowed. However, it would be best if the AI
@@ -127,7 +125,6 @@
 
 From: 	Robert A Duff
 Sent: 	Tuesday, February 02, 1999 9:58 AM
-Subject: 	Re: AI-00204
 
 > Interface packages such as Interfaces.Fortran shall not be provided if
 > the implementation does not support the interfacing pragma for that
@@ -172,7 +169,6 @@
 
 From: 	Robert Dewar
 Sent: 	Tuesday, February 02, 1999 7:16 AM
-Subject: 	Re: AI-00204
 
 <<Interface packages such as Interfaces.Fortran shall not be provided if
 the implementation does not support the interfacing pragma for that
@@ -211,7 +207,6 @@
 
 From: 	Randy Brukardt
 Sent: 	Tuesday, February 02, 1999 12:35 PM
-Subject: 	RE: AI-00204
 
 Robert commenting on the AI:
 
@@ -274,7 +269,6 @@
 
 From: 	john barnes[SMTP:jgpb@JBINFO.DEMON.CO.UK]
 Sent: 	Wednesday, February 03, 1999 3:13 AM
-Subject: 	ai-204
 
  Clearly this is going to have to be discussed again.
 
@@ -295,7 +289,6 @@
 
 From: 	Erhard Ploedereder
 Sent: 	Wednesday, February 03, 1999 6:58 AM
-Subject: 	Re: AI-00204
 
 >> Interface packages such as Interfaces.Fortran shall not be provided if
 >> the implementation does not support the interfacing pragma for that
@@ -329,7 +322,6 @@
 
 From: 	Robert Dewar[SMTP:dewar@GNAT.COM]
 Sent: 	Wednesday, February 03, 1999 7:27 AM
-Subject: 	Re: AI-00204
 
 <<I think it is neither silly nor wrong, just badly worded. It should not
 say "interfacing pragma" but rather "convention pragma".
@@ -355,7 +347,6 @@
 
 From: 	Robert A Duff[SMTP:bobduff@WORLD.STD.COM]
 Sent: 	Wednesday, February 03, 1999 10:02 AM
-Subject: 	Re: AI-00204
 
 I really think the ARG has no business modifying the RM unless there's a
 good reason.  There's no support in the RM for this imagined
@@ -371,7 +362,6 @@
 
 From: 	Erhard Ploedereder[SMTP:ploedere@INFORMATIK.UNI-STUTTGART.DE]
 Sent: 	Wednesday, February 03, 1999 10:59 AM
-Subject: 	Re: ai-204
 
 Robert writes:
 > Obvoiously the COBOL interfaces package is VERY useful even if you do not
@@ -397,9 +387,19 @@
 
 ****************************************************************
 
+From: 	Robert Dewar
+Sent: 	Wednesday, February 03, 1999 11:38 AM
+
+Yes, and there is no issue of it violating "each type in Interfaces.COBOL
+is COBOL-compatible". This is indeed true even if there is no pragma around
+and no COBOL compiler around. It is not the case that the only way to make
+things COBOL-comptible is using a pragma Convention. Who knows what
+magic is in the private part of Interfaces.COBOL and in its body????
+
+****************************************************************
+
 From: 	Erhard Ploedereder[SMTP:ploedere@INFORMATIK.UNI-STUTTGART.DE]
 Sent: 	Wednesday, February 03, 1999 11:21 AM
-Subject: 	Re: AI-00204
 
 > I really think the ARG has no business modifying the RM unless there's a
 > good reason.  There's no support in the RM for this imagined
@@ -417,6 +417,412 @@
 above by saying that these types shall be ..., IF pragma Convention is
 supported. I sure hope that at least that's a universally agreed requirement
 or else these Interface packages become a complete joke.
+
+****************************************************************
+
+From: 	Randy Brukardt
+Sent: 	Wednesday, February 03, 1999 4:08 PM
+
+>I am completely unable to read this restriction into the RM (and of course
+>if it is there it is obviously wrong), but please restate your argument
+>that this restriction is already there
+
+B.3(61) says that an implementation SHALL support pragma convention for
+a C-eligible type. (Each of the other sections have similar language). B.1(14-17)
+makes it clear that such types can be constructed from the types in the package.
+I don't see how you can get around the fact that the language ties the two
+together.
+
+Anyway, I see a larger problem here: there is absolutely nothing normative
+in the manual that says that these packages are NOT required of all
+implementations. The only thing that comes close is the Implementation
+Advice in B.2(13), which says that implementions ought to support these
+packages. But unless the section defining the package says that it is optional
+(and these don't), they are a required part of the standard.  (Remember, B
+is not a Specialized Needs Annex!!!). The Implementation Advice proves
+intent, but that's all it can do (especially because it never says that you
+don't have to implement these packages).
+
+So, now I'm certain that this needs to be a Binding Interpretation (at least to
+get to the Dewar/Duff position). Unless of course we solve Robert's
+complaint by requiring Interfaces.COBOL of all implementations...
+
+
+                                        Randy.
+
+****************************************************************
+
+From: 	Jean-Pierre Rosen
+Sent: 	Wednesday, February 03, 1999 12:46 PM
+
+Robert says:
+>Interfaces.COBOL is very useful even if you do not support pragma
+>Convention (COBOL, xxx).
+>
+>Remember that Interfaces.COBOL is provided as part of the feature for
+>interfacing with COBOL, fine in this context of course you need the
+>pragmas.
+>
+>But if you can't interface with COBOL, because there is no COBOL
+>compiler, then of course the RM does not force you to interface with
+>COBOL!!!
+
+But, as you said, the goal is to be able to interface with Cobol data.
+This does not require a COBOL compiler, but it would be logical to be
+able to have a pragma Convention COBOL for data types - at least.
+
+Of course, you can argue that you can use only COBOL data types
+defined in package Interfaces.COBOL, not user defined ones. It just
+doesn't seem consistent to me.
+
+****************************************************************
+
+From: 	Robert Dewar
+Sent: 	Thursday, February 04, 1999 6:42 AM
+
+<<But, as you said, the goal is to be able to interface with Cobol data.
+This does not require a COBOL compiler, but it would be logical to be
+able to have a pragma Convention COBOL for data types - at least.
+
+Of course, you can argue that you can use only COBOL data types
+defined in package Interfaces.COBOL, not user defined ones. It just
+doesn't seem consistent to me.
+>>
+
+Fully implementing pragma convention COBOL is a much bigger job than just
+implementing Interfaces.COBOL.
+
+Interfaces.COBOL is useful even if you don't have pragma Convention COBOL.
+
+So why do you want to tell a user: "sorry, I know you would find it useful
+to have Interfaces.COBOL, and I would be happy to provide it to you, but the
+ARG says I can't do that unless I also provide pragma Convention COBOL, so
+you can't have it. Yes, I know you don't need pragma Convention COBOL, but
+that's the way the rule is. Yes, I know it makes no sense, don't ask me,
+complain to the ARG.
+
+Being able to deal with primitive COBOL data elements is definitely useful
+on its own, without the full mechanism of, e.g. copying the effect of
+alignment on COBOL records (indeed we provide no built in mechanism anyway
+for dealing with SYNCHRONIZED, so a useful implementation of pragma
+Convention COBOL would have to include an extra pragma to handle
+SYNCHRONIZED in any case, and for sure the RM does not require that.
+
+So really what you are threatening to say is
+
+You may not provide the useful facility Interfaces.COBOL unless you also
+provide a partial implementation of pragma Convention COBOL that is unlikely
+to be of use.
+
+This makes no sense. I am amazed that we even spend time discussing the
+possibility of such an obviously stupid restriction.
+
+It is certainly nice if all compilers provide all features (right now in
+the real world, I think only GNAT provides Interfaces.COBOL in any case,
+and it fully implements interfacing to COBOL [on appropriate machines we
+pass the test of actually calling COBOL].
+
+The approach being suggested here means that GNAT would have to remove
+Interfaces.COBOL on some machines if we really insisted in actual interfacing,
+well thankfully that silly idea seems to be gone, and GNAT does always allow
+pragma Convention COBOL.
+
+But what about other compilers? I think it would be useful to encourage
+people to provide Interfaces.COBOL even if they don't provide other useful
+stuff. In fact I think other compilers could even adopt the GNAT
+implementation, I don't think it relies on non-standard features (Aonix
+did this for a while for some of the math routines, given the GPL status
+it is quite legitimate to do this).
+
+Why on EARTH would we tell other vendors that they cannot provide this
+useful facility. It boggles the mind for the ARG to be in the business
+of issuing rules that are detrimental to implementors and users alike!
+
+****************************************************************
+
+From: 	Randy Brukardt
+Sent: 	Thursday, February 04, 1999 10:21 AM
+
+>Interfaces.COBOL is useful even if you don't have pragma Convention COBOL.
+
+If we're going to allow compilers to support features of dubious utility, then there is
+no advantage to these packages being optional. We should just follow the wording
+(not the intent) of the RM, and require them of everyone. Implementing simple
+versions of these packages is just about trivial, if you make no requirement about
+the types being compatible with a particular compiler. (Which is what Robert is
+saying he wants - because that is what the effect of not requiring a pragma
+Convention.)
+
+                                                        Randy.
+
+****************************************************************
+
+From: 	Tucker Taft
+Sent: 	Thursday, February 04, 1999 5:16 PM
+
+Randy Brukardt wrote:
+> 
+> >I am completely unable to read this restriction into the RM (and of course
+> >if it is there it is obviously wrong), but please restate your argument
+> >that this restriction is already there
+> 
+> B.3(61) says that an implementation SHALL support pragma convention for
+> a C-eligible type. (Each of the other sections have similar language). B.1(14-17)
+> makes it clear that such types can be constructed from the types in the package.
+> I don't see how you can get around the fact that the language ties the two
+> together.
+
+Well, I sort of hate to wade into this morass.  However,
+what B.3(61) says, in my view, is that to support *interfacing
+to C*, the implementation must support convention C.  B.3(1), 
+similarly, indicates that to support *interfacing to C*,
+the implementation must provide the package Interfaces.C and
+its children.  Nowhere does it say that if the implementation
+does *not* fully support interfacing to C, then it must *not*
+provide Interfaces.C, nor for that matter must it *not* support
+pragma Convention C.
+
+For the Specialized Needs annexes, we clearly allow subset
+implementations, so long as the implementation does not claim 
+to fully support the annex.
+
+I believe we have adopted this same attitude relative to Annex B
+(even though it is not officially a Special Needs Annex), that
+implementations need not fully support interfacing to all languages.
+Nowhere do I see a requirement for an all or nothing support of
+interfacing to a particular language.
+ 
+> ...
+> So, now I'm certain that this needs to be a Binding Interpretation (at least to
+> get to the Dewar/Duff position). Unless of course we solve Robert's
+> complaint by requiring Interfaces.COBOL of all implementations...
+> 
+
+I agree we should make it clear that support for particular "foreign"
+languages is optional, and that the support may be partial support
+or full support.
+
+Full support requires supporting both the corresponding Interfaces.*
+package(s) and the corresponding convention.  Partial support
+is any well-defined subset of that, using the guidelines of 1.1.3(17)
+for indicating what is a "well-defined subset."  E.g., the unsupported
+capability shall be identified before run-time, or by an exception
+at run-time.  There is no all-or-nothing requirement.
+
+****************************************************************
+
+From: 	john barnes
+Sent: 	Friday, February 05, 1999 2:05 AM
+
+In message stt@AVERSTAR.COM writes:
+>
+> Well, I sort of hate to wade into this morass.  However,
+> what B.3(61) says, in my view, is that to support *interfacing
+> to C*, the implementation must support convention C.  B.3(1),
+> similarly, indicates that to support *interfacing to C*,
+> the implementation must provide the package Interfaces.C and
+> its children.  Nowhere does it say that if the implementation
+> does *not* fully support interfacing to C, then it must *not*
+> provide Interfaces.C, nor for that matter must it *not* support
+> pragma Convention C.
+
+So the "should" in B.2(12) is overridden by an implicit "shall" in
+B.3(1).
+
+As a result (as writtne) the "should" only applies to languages other
+than C, COBOL and Fortran so those three languages are special. Not
+quite what I would have expected. I would have expected Ada to treat
+all languages the same except that it tells you what to do if you
+want to support C, COBOL and Fortran but leaves you on your own
+for others.
+
+****************************************************************
+
+From: 	Erhard Ploedereder
+Sent: 	Friday, February 05, 1999 12:13 PM
+
+Erhard:
+<<So, if Bob's and Robert's opinion carries, the AI would need to be rewritten
+to be a binding interpretation, nullifying the Annex B paragraphs cited
+above by saying that these types shall be ..., IF pragma Convention is
+supported. I sure hope that at least that's a universally agreed requirement
+or else these Interface packages become a complete joke.
+>>
+
+Robert:
+> Sorry, I don't get the joke, what are you talking about here???
+
+I am talking about the view that any user of the packages will have: he
+will expect that the effects of a pragma Convention, whatever
+they may be on binary infacing of data, apply to the types in these
+packages. I.e., Interfaces.C.long_double really,really is of the same
+representation as in C.
+
+Note that in the position that you're pushing, Interfaces.C is perfectly
+conforming to the Standard if it defines
+    type long_double is digits 6;  -- too busy to worry about it now
+
+I am struggling with the question of what to tell the user, when he asks:
+What must be the case, so that I can assume Interfaces.C.long_double is
+binary compatible with the long_double in my C program ?
+
+The AI in its current form would say (and so does the RM today): This is the
+case, if the package exists. No major buts and ifs. (Maybe a few minor buts
+and ifs, well documented.:-)
+
+My original response quoted at the beginning of this message tried a
+compromise: Yes, there is a "if", namely support for pragma Convention.
+
+I am certainly unhappy about the answer: "Oh, you thought this type
+declaration in the Interface package means something other than a name ?
+Sorry, it really is just a name and an implementation need not guarantee
+anything about the type."
+
+****************************************************************
+
+From: 	Robert A Duff
+Sent: 	Friday, February 05, 1999 1:19 PM
+
+> Note that in the position that you're pushing, Interfaces.C is perfectly
+> conforming to the Standard if it defines
+>     type long_double is digits 6;  -- too busy to worry about it now
+
+No, that would not be conforming.  I admit that the ACVC would not catch
+it, but that's a separate issue.  I don't see how the AI negates this
+requirement.
+
+Note that support for pragma Convention is not the same thing as the
+conventions of things in these packages.  We always assumed that
+Interfaces.C.long_double would get it's convention "by magic" in many
+(most?)  implementations -- not via pragma Convention.
+
+- Bob
+
+****************************************************************
+
+From: 	Robert I. Eachus
+Sent: 	Friday, February 05, 1999 1:17 PM
+
+>                                                 However,
+> what B.3(61) says, in my view, is that to support *interfacing
+> to C*, the implementation must support convention C.  B.3(1),
+> similarly, indicates that to support *interfacing to C*,
+> the implementation must provide the package Interfaces.C and
+> its children.  Nowhere does it say that if the implementation
+> does *not* fully support interfacing to C, then it must *not*
+> provide Interfaces.C, nor for that matter must it *not* support
+> pragma Convention C.
+
+   And I agree with this as well.  In 1.1.3(16) we read (all emphasis mine):
+
+"An implementation that conforms to this Standard shall support each
+capability required by the core language as specified."
+
+   In B.2(11) I see:
+
+     Implementation Permissions
+
+"An implementation MAY provide implementation-defined library units that
+are children of Interfaces, and may add declarations to the visible part of
+Interfaces in addition to the ones defined above."
+
+   Later B.2(13):
+
+     Implementation Advice
+
+"An implemenation supporting an interface to C, COBOL, or Fortran SHOULD
+provide the corresponding packages described in the following clauses."
+
+   And back to Chaper 1.1.3(17):
+
+"An implementation conforming to this International Standard MAY provide
+additional attributes, LIBRARY UNITS, and pragmas.  However, it shall not
+provide any attribute, library unit, or pragma having the same name as an
+attribute, library unit or pragma(respectively) specified in a Specialized
+Needs Annex unless the provided construct is either as specified in the
+Specialized Needs Annex or is more limited in capability than that required
+by the Annex."
+
+   So there seems to be NO way to reject an implementation that provides a
+package Interfaces.Cobol or Interfaces.C no matter what is in the package.
+IF Annex B was a Specialized Needs Annex, there would still be no
+justification for rejecting a child of Interfaces that conforms to the
+Standard.  We might want to extend 1.1.3 to include that requirement, but
+it is not there now. But it is real hard to argue that may in B.2(11) away.
+
+****************************************************************
+
+From: 	john barnes
+Sent: 	Saturday, February 06, 1999 2:00 AM
+
+> At 08:05 AM 2/5/99 GMT, john barnes wrote:
+>
+> >So the "should" in B.2(12) is overridden by an implicit "shall" in
+> >B.3(1).
+
+I was stating what I thought Tuck said B.3(1) meant. Not that I personally
+necessarily believed it.
+
+I could interpret B.3(1) as stating these things (packages and pragmas) are
+the domain of discourse but not imposing any requirements.
+
+>
+>    That is a real stretch that ignores the one paragraph between them,
+> B.2(13) quoted above.  I don't see any reason for reading a 'shall' into
+> B.3(1), when it is preceded by an unambigous 'should'.
+>
+
+Yes that's two shoulds versus one suspected shall.
+
+I agree.
+
+
+However, maybe we should concentrate on what we want and then decide how the
+RM should be fixed if it doesn't provide it.
+
+****************************************************************
+
+From: 	Tucker Taft
+Sent: 	Saturday, February 06, 1999 7:31 AM
+
+> > At 08:05 AM 2/5/99 GMT, john barnes wrote:
+> >
+> > >So the "should" in B.2(12) is overridden by an implicit "shall" in
+> > >B.3(1).
+>
+> I was stating what I thought Tuck said B.3(1) meant. Not that I personally
+> necessarily believed it.
+
+Then I was unclear (I suspect you didn't notice one of my "not"s in
+the message -- I got carried away with double negatives).
+
+What I was *trying* to suggest was that support for foreign
+languages is effectively optional.  Furthermore, there is no "all or nothing"
+requirement for supporting a particular language.  You may provide
+the Interfaces.X package, or the pragma for convention X, or neither,
+or both.  However, to claim to "fully support interfacing to X" you
+must supply both.
+
+Some have argued (I think) that providing Interfaces.X without
+supporting pragma convention X is not useful, or is misleading.
+I don't agree, but in any case, I don't see any justification
+for requiring an all-or-nothing rule here, while we don't require
+an all-or-nothing rule in the Specialized Needs Annexes.
+
+> ...
+> Yes that's two shoulds versus one suspected shall.
+>
+> I agree.
+>
+>
+> However, maybe we should concentrate on what we want and then decide how the
+> RM should be fixed if it doesn't provide it.
+
+I think we should make it more clear that support for foreign languages
+is optional, and that partial support is allowed.  Whether this
+is a binding interpretation or a ramification or a confirmation seems
+relatively minor in my view.  I will happily sign up for whatever
+categorization the majority believes is most appropriate.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent