!standard B.5 (00) 99-09-24 AI95-00204/02 !class binding interpretation 99-09-24 !status work item 99-02-02 !status received 98-03-27 !priority High !difficulty Medium !subject Interfaces.Fortran must be absent, right? !summary Interface packages such as Interfaces.Fortran may be provided independently of whether the implementation supports the interfacing pragma for that language. This applies also to other foreign languages including C and COBOL. !question Is it permitted to provide a package Interfaces.Fortran even if pragma convention Fortran is not supported? (Yes.) !recommendation (See summary.) !wording Replace the first sentence of B.2(12) which states "For each implementation-defined convention identifier, there should be a child package of package Interfaces with the corresponding name." by "A child package of package Interfaces with the name of a convention may be provided irrespective of whether the convention is supported by the pragma Convention." !discussion There are two primary reasons for interfacing to another language such as Fortran. One is to access data in the conventions of that language and the other is to call code written in that language. Ada provides two techniques for such interfacing. One is the pragma convention with appropriate parameter and the other is the existence of packages such as Interfaces.Fortran. It is the intention that either or both of these techniques may be provided independently for a given language. Thus the package Interfaces.Fortran provides types that are sufficient for interfacing as stated by B.5(2) irrespective of whether the pragma Convention is supported for Fortran. This is in apparent contradiction to B.2(12) which seems to imply that an interface package can only be provided if the corresponding pragma Convention is supported. Similar rules apply to other foreign languages. !corrigendum B.02(12) @dprepl For each implementation-defined convention identifier, there should be a child package of package Interfaces with the corresponding name. @dby A child package of package Interfaces with the name of a convention may be provided irrespective of whether the convention is supported by the pragma Convention. !ACATS test This is a permission to do something, so it is untestable by itself. The underlying features are throughly tested by the ACATS. !appendix !section B.5(00) !subject interfaces.fortran must be absent, right? !reference AARM-B.5 !from Samuel T. Gregory 98-03-19 !reference 1998-15830.a Samuel T. Gregory 1998-3-19>> !discussion Because of a lack of a FORTRAN compiler, and lack of (scheduled) time to get FORTRAN unconstrained array parameters right before scheduling an AVF, we were not going to claim to interface to FORTRAN, then someone here typed in INTERFACES.FORTRAN and checked it into our runtime. Now, instead of getting an error on the "with Interfaces.Fortran" lines of CXB50042 and CXB50052, we get other errors later on. Please confirm that INTERFACES.FORTRAN must actually be absent in order for an implementation not to claim to interface to FORTRAN and not have the FORTRAN acvc tests apply. Or tell us the real criteria. Ivan's reasoning follows: - B.5(20) requires us to support convention FORTRAN for a FORTRAN-eligible type. - B.1(14-18) defines a FORTRAN-eligible type as one that either is, or has only components that are, FORTRAN-compatible. - B.1(13) says that a type is FORTRAN-compatible if it's declared in package INTERFACES.FORTRAN or it's defined to be FORTRAN-COMPATIBLE. - B.5(18) requires us to claim that the specified types (ie. all of them in INTERFACES.FORTRAN) are FORTRAN-compatible. - Ergo, if we provide INTERFACES.FORTRAN, then we must support convention FORTRAN for any type that is derived from, or has components of, any type within INTERFACES.FORTRAN. - But, if we don't provide INTERFACES.FORTRAN, then B.1(20) allows us to claim that we don't permit *any* FORTRAN-compatible type, and therefore, that there are *no* FORTRAN-eligible types in our implementation, and therefore, that B.5(20) is moot. **************************************************************** From: Brashear, Phil Sent: Friday, January 29, 1999 7:34 AM On tests CXB5004 and CXB5005, an implementation rejects the Import pragma because they do not define convention Fortran. As shown by CXB5001..3, they do provide package Interface.Fortran, but they don't support actual linkages to Fortran code. The tests expect an implementation not fully supporting Fortran interfaces to reject "with Interface.Fortran;" In the past, we have had implementations do that and have also had implementations that accept the entire program but fail at link time (because no Fortran compiler is available). Both behaviors have been graded Not-Applicable. We believe that rejecting the pragma (because of the undefined convention Fortran) is a third way to handle this situation. Is this acceptable? **************************************************************** From: Brukardt, Randy Sent: Friday, January 29, 1999 1:33 PM 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 write-up made clear whether or not the package Interface.Fortran implies support for convention Fortran, and vice versa. (Of course, any such result should apply to all language conventions). **************************************************************** From: Robert A Duff Sent: Tuesday, February 02, 1999 9:58 AM > Interface packages such as Interfaces.Fortran shall not be provided if > the implementation does not support the interfacing pragma for that > language. This applies also to other foreign languages including C and > COBOL. I think the ruling is silly. It's perfectly harmless to have "extra" Interfaces.* packages lying around. And there's nothing in the RM saying otherwise. First, Implementation Advice ("should" rules) don't count. Second, the Impl Advice quoted in the AI, B.2(12) doesn't say the same thing as the AI -- it says that if you support convention X, you *should* have a package Interfaces.X. Not the other way around. Note that the AI claims to be a "confirmation", so it ought to follow from the RM rules. Preferably in an "obvious" way! ;-) Whether such "extra" packages are useful or not is irrelevant. The ARG is not in the business of forbidding useless things. Such packages are harmless, and the RM doesn't forbid them. Therefore they're allowed. The only reason this came up is because some ACVC tests have both a "with Interfaces.Fortran" and also "pragma Convention(Fortran, ...)". The grading criteria say that if the implementation complains about the with-clause, that's OK, but if the implementation complains about the pragma, that's not OK. So we have a case of some test writer being slightly confused, and the ARG then making that into law, by sheer invention of rules. Some of our implementations currently violate this rule. It would be easy to fix -- we just have to delete the package Interfaces.Fortran. Or, more likely, save it away somewhere for when we ever get around to finishing the implementation of Fortran interfacing. Therefore, from a practical point of view, I don't much care which way this turns out. The reason I'm saying something about it is that I don't like the idea of test-driven language rulings (as opposed to RM-driven, or user-needs-driven). - Bob **************************************************************** From: Robert Dewar Sent: Tuesday, February 02, 1999 7:16 AM <> I find this completely wrong, it is extremely useful to have Interfaces.COBOL around even if there is no COBOL compiler around. As I read the AI, it is written up with exactly the contrary view. <> It is that sentence that seems plain wrong, why does there have to be at least one such compiler around. I can't really speak for Fortran here, but for example, GNAT always provides Interfaces.COBOL using standard IBM data formats shared by many compilers. This is useful on ALL machines, including those with no COBOL compiler, since it allows an Ada program to read and process files generated by an IBM-compatible COBOL compiler. Perhaps I read the AI wrong, but certainly the summary and the above quoted sentence seem to come to exactly the wrong conclusion here. It is never helpful to force compilers to remove a useful feature for the sake of some theoretical, and in this case plain silly, formal reason. **************************************************************** From: Randy Brukardt Sent: Tuesday, February 02, 1999 12:35 PM Robert commenting on the AI: <> I find this completely wrong, it is extremely useful to have Interfaces.COBOL around even if there is no COBOL compiler around. As I read the AI, it is written up with exactly the contrary view. Randy: Supporting the Interfacing pragma does not require that a compiler exist. Indeed, to properly support data representations, the convention name COBOL, Fortran, etc. HAS to be supported. If you know what compiler you are supporting, you can generate appropriate import/export code. You don't need to actually have a compiler. Back to Robert: <> It is that sentence that seems plain wrong, why does there have to be at least one such compiler around. I can't really speak for Fortran here, but for example, GNAT always provides Interfaces.COBOL using standard IBM data formats shared by many compilers. This is useful on ALL machines, including those with no COBOL compiler, since it allows an Ada program to read and process files generated by an IBM-compatible COBOL compiler. Randy says: I totally agree that no compiler should be allowed. I'm not so convinced about the laissez-faire approach to handling this. It means that a user cannot really depend on anything about interfacing (if X is supported, that tells us nothing about whether anything else works), and it makes interfacing untestable. (It would not be possible to fail the tests - they would always be not applicable.) In that case, I would rather withdraw the tests as of no value - the only value they would have is to an implementor testing their compiler in-house, and that is not the purpose of the ACATS. Therefore, I think we HAVE to have some rules as to what support is required if any support is. Randy. **************************************************************** From: john barnes[SMTP:jgpb@JBINFO.DEMON.CO.UK] Sent: Wednesday, February 03, 1999 3:13 AM Clearly this is going to have to be discussed again. I don't have very strong feelings about this topic. I wrote the AI as directed by the meeting and as written up in the minutes. But I thought it would prompt further discussion. Robert's point that the conventions might be well defined by some other standard even if only de facto rather than having to refer to an actual compiler is a very good one. It's no doubt better to have the conventions defined by a standard than by some wretched compiler. But I think it's untidy and confusing to provide an interfaces package without supporting the convention pragma and that was certainly strongly felt at the meeting if I recall correctly. However, everyone wasn't present. John **************************************************************** From: Erhard Ploedereder Sent: Wednesday, February 03, 1999 6:58 AM >> Interface packages such as Interfaces.Fortran shall not be provided if >> the implementation does not support the interfacing pragma for that >> language. This applies also to other foreign languages including C and >> COBOL. Bob: > I think the ruling is silly. It's perfectly harmless to have "extra" > Interfaces.* packages lying around. And there's nothing in the RM > saying otherwise. Robert: > I find this completely wrong, it is extremely useful to have > Interfaces.COBOL around even if there is no COBOL compiler around. I think it is neither silly nor wrong, just badly worded. It should not say "interfacing pragma" but rather "convention pragma". Look at the comment that prompted this whole issue. Do we consider it to be conformant, if somebody types in the package spec, provides some dummy Ada bodies that in effect convert Ada to Ada, and that's it ?? This is in gross violation of RM B.2(1), B.5(2) and RM B.5(20), combined with 1.1.3(17). Put simply: "You are not allowed to provide a package with the same name as the predefined one that doesn't do what the RM prescribes, in this case that the types have Fortran convention representation." Erhard **************************************************************** From: Robert Dewar[SMTP:dewar@GNAT.COM] Sent: Wednesday, February 03, 1999 7:27 AM <> Nope, that's wrong too. 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!!! However, you can still implement any or all of the relevant section to provide useful facilities to a user, providing you implement them correctly. **************************************************************** From: Robert A Duff[SMTP:bobduff@WORLD.STD.COM] Sent: Wednesday, February 03, 1999 10:02 AM 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 restriction. Therefore, to apply such a restriction, the ARG should first argue that there's some concrete benefit to users, which I haven't seen. I've seen John saying it seems untidy, and Erhard being outraged at implementor laziness, which may well be true -- bit it's pretty marginal. - Bob **************************************************************** From: Erhard Ploedereder[SMTP:ploedere@INFORMATIK.UNI-STUTTGART.DE] Sent: Wednesday, February 03, 1999 10:59 AM Robert writes: > Obvoiously the COBOL interfaces package is VERY useful even if you do not > support the [convention] pragma. Hmmm. Interfaces.COBOL might be a special case. Let me replay your argument in my words to check whether I got it.... Because Interfaces.COBOL has all these Display_Format operations, it's useful even if B.4(51) ("each type in Interfaces.COBOL is COBOL-compatible") is violated. For really interfacing with COBOL at a binary level, you obviously need the support of the various pragmas, but for writing text files matching COBOL-expectations, the package alone is enough and pretty useful. Is that it ? (I looked at Interfaces.C, too. And there similar benefits would be much more marginal (Is_Nul_Terminated might be useful) and, in my opinion, even detrimental if used as a packaged way of unsafe programming, c.f., Interfaces.C.Strings. For Interfaces.Fortran the benefits are non-existent, since it lacks any useful interfaces. **************************************************************** 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 > 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 > restriction. Well, it's a confirmation AI. We're not modifying the RM. And RM B.2(1), B.5(2), B.5(18) [and analogous sentences for the other language packages], combined with 1.1.3(17), are repeated and ample justification to call this a !confirmation. How you can read these paragraphs and come to a different conclusion is beyond my understanding, but I'm listening :-) 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. **************************************************************** 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 <> 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: <> 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. **************************************************************** From: Jean-Pierre Rosen Sent: Saturday, September 25, 1999 4:21 AM > !corrigendum > > Replace the first sentence of B.2(12) which states > > "For each implementation-defined convention identifier, there should be > a child package of package Interfaces with the corresponding name." > > by > > "A child package of package Interfaces with the name of a convention may > be provided irrespective of whether the convention is supported by the > pragma Convention." > > I think "replace" should be "add after". What the old paragraph says, is that if you support a convention, you'd better provide the corresponding package, which makes sense to me: if you interface with programs, you'd better interface with data also (note that there is a "should"). OTOH, what the second paragraph says is that you can provide the package even if you don't support the convention. I'm OK with that, but I don't think it subsumes the first paragraph. **************************************************************** From: John Barnes Sent: Saturday, October 2, 1999 7:26 AM The original view of the ARG was that you can provide the convention pragma with or without the package (the paragraph says should not shall) but not the package without the pragma. But the meeting in Burlington changed its mind to say let either be provided independently. Hence I rewrote it that way. ****************************************************************