CVS difference for ais/ai-00284.txt

Differences between 1.8 and version 1.9
Log of other versions for file ais/ai-00284.txt

--- ais/ai-00284.txt	2003/09/30 02:01:11	1.8
+++ ais/ai-00284.txt	2003/10/29 22:54:11	1.9
@@ -722,3 +722,207 @@
 
 *************************************************************
 
+From: Robert Dewar
+Sent: Monday, September 29, 2003  9:23 PM
+
+> The problem, of course, is the Ada 83 pragma Interface. While that is no
+> longer in the standard, we don't want to make it illegal for implementations
+> to support such a pragma.
+
+Just allow implementations to support pragmas whose names are reserved.
+I don't see a problem, we allow this for attributes. This would be no
+implementation difficulty as far as I can see, and is only there for
+implementations that want to fiddle with interface.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Monday, September 29, 2003  9:28 PM
+
+> I believe there
+> is a child package named GNAT.<whatever>.Interface in
+> the GNAT library, as an example of a typical conflict.
+
+Well if that is a typical example, worry less, since it does not exist :-)
+
+> So as long as the interface type proposal doesn't get
+> shot down because of the use of a new reserved word,
+> I certainly don't have any compelling desire to introduce
+> the complexity of non-reserved keywords.  *But*, if the
+> incompatilibity concerns suddenly blossom again, then
+> I'm all for using the appropriate word in the syntax
+> and living with the non-reserved keyword approach.
+
+I have exactly the opposite viewpoint. I am quite OK with the interface
+type proposal, IF AND ONLY IF interface is a new keyword, otherwise I
+would prefer to look for alternatives.
+
+I find this business of "we really want new keyword xxx, but we don't
+want more reserved keywords, so we will make it unreserved" extremely
+ugly. Since the idea of nice syntactical ideas is to improve the syntax
+of the language, such approaches always fail for me, because the damage
+done by the introduction of this weird non-orthogonal feature is too
+serious.
+
+I would rather have NOT WITH IN OUT ENTRY or some such drivel than
+non-reserved keywords :-)
+
+*************************************************************
+
+From: Arnaud Charlet
+Sent: Tuesday, September 30, 2003  1:58 AM
+
+> "Interface" is the real issue.  I believe there
+> is a child package named GNAT.<whatever>.Interface in
+> the GNAT library, as an example of a typical
+> conflict.
+
+As Robert said, there's no such example.
+I believe the only example given during past discussion was
+GNATCOM.Interface or some such. But then, I'm sure David would have
+no trouble renaming it to something else (e.g. GNATCOM.Interfaces)
+for the next version of GNATCOM. Generally speaking, any example of
+the use of 'Interface' in free software should not be considered as a
+showstopper, since free software typically evolves rapidly and can be
+modified by anyone freely.
+
+I also do not like the idea of unreserved keywords, and would rather
+introduce a couple new keywords in the language.
+
+*************************************************************
+
+From: John Barnes
+Sent: Tuesday, September 30, 2003  2:07 AM
+
+>> *As far as I know, the two "unreserved" keywords being considered
+>> are INTERFACE and OVERRIDES.  Are there any others?
+[attribution lost]
+
+It's OVERRIDING actually.
+
+*************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, September 30, 2003  3:39 AM
+
+> > I believe there
+> > is a child package named GNAT.<whatever>.Interface in
+> > the GNAT library, as an example of a typical
+> > conflict.
+>
+> Well if that is a typical example, worry less, since it does
+> not exist :-)
+
+I think Tuck was referring to GNATCOM.Interface.  Last time I checked,
+this did exist.  It is pretty hard to do anything useful on Windows
+without GNATCOM, and it's pretty hard to do anything with COM without
+interfaces, so I would guess that there would be quite a few users of
+that package.  Forcing then to update their code just because someone
+didn't like unreserved keywords would be irresponsible in my opinion.
+Surely we are talking about a much larger impact than, say, the
+introduction of "aliased" or "tagged".
+
+On the other hand, I suppose that I should not worry too much about a
+language change that would make life difficult _only_ for users of GNAT.
+:->
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, September 30, 2003  4:25 PM
+
+Well this is an Ada Core product, and so I think our opinion should count
+for something.
+
+> On the other hand, I suppose that I should not worry too much about a
+> language change that would make life difficult _only_ for users of GNAT.
+
+If we don't consider it a problem, I hardly think that Pascal has a strong
+argument in this particular case :-)
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, September 30, 2003  4:27 PM
+
+In general let me say that here at Ada Core, we are of course reluctant
+to introduce non-compatible changes. But we will do so if
+
+a) it really is a cleanup
+b) the effort of change is small
+
+An example is our restriction identifier No_Tasking, introduced because
+the RM would not allow us to diagnose Max_Tasks => 0 at compile time.
+But the ARG fixed this (thank you) and now we will get rid of No_Tasking,
+even though this means that some users will have to change their code
+to use the (now) standard form Max_Tasks => 0.
+
+*************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Tuesday, September 30, 2003  2:33 AM
+
+Bob Duff said:
+...
+> If we do go with "unreserved keywords" (which I think is probably a good
+> idea), I suggest the test suite add explicit tests that these words are
+> indeed unreserved.
+
+I guess the difference between you and me is that I do not like "unreserved"
+keywords. I've been teaching for years that Ada is a carefully designed piece
+of work, and this looks like an ugly kludge with no other reason than
+compatibility. I am really concerned that people from other languages will
+lough at us on this.
+
+Now, if you tell me that these words *are* reserved, but the compiler is
+allowed to have a mode where they are still accepted for compatibility (but not
+necessarily an Ada95-only mode), I could buy that.
+
+In non-standard mode, a compiler can do 100% what it pleases (including
+compiling FORTRAN). I really don't want to prevent validation of a compiler
+that would treat all keywords as reserved words.
+
+As far as portability is concerned, a program that would use these keywords as
+identifiers would not be portable, full stop.
+
+*************************************************************
+
+From: Robert I. Eachus
+Sent: Tuesday, September 30, 2003  11:19 AM
+
+
+Randy wrote:
+
+> The problem, of course, is the Ada 83 pragma Interface. While that is no
+> longer in the standard, we don't want to make it illegal for implementations
+> to support such a pragma.
+>
+> I suppose that could be fixed by defining it to be obsolecent (then using
+> the reserved word for a name would be allowed), but it seems like a messy
+> fix.
+
+If it isn't in Annex J currently (or anywhere else in the ARM) why add it back
+in?  Yes compilers could support an Ada 83 mode, or even allow this in an Ada
+95 mode.  But otherwise I think it comes under the same heading as user defined
+names.  If someone wants to use the Ada 0Y features they have to change all
+occurances of pragma Interface to pragma Import, if they haven't already.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, September 30, 2003  5:29 PM
+
+Because an implementation-defined pragma cannot be named with a reserved
+word. (Yes, we could change that, as Robert Dewar suggests). But I don't
+think the incompatibility of disallowing Interface (a commonly used pragma
+in older code) is going to fly.
+
+*************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, September 30, 2003 10:15 PM
+
+So you can always allow it in non-standard mode :-)
+
+*************************************************************
+

Questions? Ask the ACAA Technical Agent