CVS difference for ais/ai-00251.txt

Differences between 1.15 and version 1.16
Log of other versions for file ais/ai-00251.txt

--- ais/ai-00251.txt	2003/09/19 01:42:26	1.15
+++ ais/ai-00251.txt	2003/09/30 02:01:11	1.16
@@ -3504,3 +3504,425 @@
 
 ****************************************************************
 
+From: Tucker Taft
+Sent: Sunday, September 28, 2003  9:51 AM
+
+I have had real trouble keeping the syntax
+for interface types in my head.  Every time
+I write an example, I get something wrong.
+I just took a look at AI-251, and I can see
+why ;-).  We aren't being consistent, and
+I suspect I am at least partly to blame.
+
+Here is the inconsistency I find most mystifying:
+
+     type T is new Q and R and S with record ... end record;
+
+     type T is new Q with R and S and private;
+
+I certainly think of "with record ...;" and "with private;"
+as similar constructs.  I feel strongly these two need
+to be reconciled somehow.
+
+And here is the form for one interface inheriting from others:
+
+     type P is interface with Q and R;
+
+(no "new" even though this is a "derived" interface).
+
+I am now trying to figure out what to propose
+for the syntax for inheriting from protected and
+task interfaces.  Here are two possibilities:
+
+     protected type T is new <interface_list> with ...
+   or:
+     protected type T with <interface_list> is ...
+
+and then there is the "derived" interface case:
+
+     protected interface PI is new <interface_list> with ...
+    or:
+     protected interface PI with <interface_list> is ...
+
+
+Any comments/suggestions?
+
+I *think* I would prefer always putting interfaces
+after the word "with", or never doing so.  The half-and-half
+approach is too confusing and hard to remember.
+
+I also feel some preference for having "new" in any
+type that is derived from something else.  As it is
+now, derived interfaces don't have "new" anywhere.
+
+A radical suggestion would be to put the word "interface"
+out front:
+
+    interface Q;
+
+    interface Q is new R and S;
+
+In any case, I found the current proposal a bit of a
+confusing mish-mosh, and the protected/task interface
+proposal seems likely to make it worse...
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, September 28, 2003  12:04 PM
+
+> A radical suggestion would be to put the word "interface"
+> out front:
+>
+>    interface Q;
+>
+>    interface Q is new R and S;
+> ...
+
+This would be treating "interface" as a
+substitution for the term "type" instead of
+as a kind of type.  This works better for protected
+and task interfaces, since the syntax clearly
+looks better with the word "type" *replaced*
+with the word "interface" rather than writing something like:
+
+    protected type interface PI is ...
+   or
+    protected interface type PI is ...
+
+So maybe this radical suggestion has something
+going for it, especially if we are considering
+generalizing it to cover protected/task interfaces.
+
+And it allows the use of "new" for derived
+interfaces, which would also be more consistent
+in my view.
+
+****************************************************************
+
+From: Vincent Celier
+Sent: Sunday, September 28, 2003  12:13 PM
+
+Ar you suggesting that these should be replaced with
+
+     protected interface PI is ...
+
+?
+
+So,
+
+     protected Interface is ...
+
+would be a single_protected_declaration, and
+
+     protected interface PI is ...
+
+would be an interface protected type declaration.
+
+I am not sure I would like that.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Sunday, September 28, 2003  12:31 PM
+
+> Ar you suggesting that these should be replaced with
+>
+>      protected interface PI is ...
+>
+> ?
+
+Yes.
+
+>
+> So,
+>
+>      protected Interface is ...
+>
+> would be a single_protected_declaration, and
+>
+>      protected interface PI is ...
+>
+> would be an interface protected type declaration.
+>
+> I am not sure I would like that.
+
+Good point.  I think here we would disallow the
+use of "Interface" as the name of a singleton protected
+(or task) object, even if interface is a non-reserved keyword.
+That seems like an acceptable incompatibility.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Monday, September 29, 2003  2:02 AM
+
+>Here is the inconsistency I find most mystifying:
+>
+>     type T is new Q and R and S with record ... end record;
+>
+>     type T is new Q with R and S and private;
+>
+>I certainly think of "with record ...;" and "with private;"
+>as similar constructs.  I feel strongly these two need
+>to be reconciled somehow.
+
+I agree that this needs fixing.  As a matter of fact, I see this discrepancy as
+a bug in the AI.  It appears that the syntax for private extension comes from
+the Vienna meeting, but at the subsequent Bedford meeting we changed the order
+of things, and came up with the syntax for record extension, above.  Evidently
+the AI was not updated consistently.
+
+>And here is the form for one interface inheriting from others:
+>
+>     type P is interface with Q and R;
+>
+>(no "new" even though this is a "derived" interface).
+
+Again this was discussed several times, and as a matter of fact I find it
+useful that there is no "new" here, as the syntax makes it clear that you are
+not declaring a derived type, but only composing interfaces.
+
+>I am now trying to figure out what to propose
+>for the syntax for inheriting from protected and
+>task interfaces.  Here are two possibilities:
+>
+>     protected type T is new <interface_list> with ...
+>   or:
+>     protected type T with <interface_list> is ...
+
+The first syntax is the one that is consistent with the Bedford decision.
+
+>and then there is the "derived" interface case:
+>
+>     protected interface PI is new <interface_list> with ...
+>    or:
+>     protected interface PI with <interface_list> is ...
+
+I am concerned by the possible lookahead problems for parsers: when you reach
+the word "interface", you don't know if it's a keyword or an identifier.
+Furthermore, this syntax is inconsistent with the interface composition syntax
+above.
+
+>Good point.  I think here we would disallow the
+>use of "Interface" as the name of a singleton protected
+>(or task) object, even if interface is a non-reserved keyword.
+>That seems like an acceptable incompatibility.
+
+This doesn't make sense at all.  The sole purpose of unreserved keywords is to
+avoid incompatibilities.  As you know, unreserved keywords are already a
+contentious issue.  Unreserved keywords with incompatibilities are sure to be
+shot down at the WG9 level.  For my part, I am going to oppose any AI that has
+such a blatant incompatibility anyway.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, September 29, 2003  5:38 AM
+
+P> I agree that this needs fixing.  As a matter of fact, I see this
+P> discrepancy as a bug in the AI.  It appears that the syntax for private
+P> extension comes from the Vienna meeting, but at the subsequent Bedford
+P> meeting we changed the order of things, and came up with the syntax for
+P> record extension, above.  Evidently the AI was not updated consistently.
+
+OK, that makes me feel better.
+Though I frankly couldn't remember which we settled
+on.  I take it that it was the first of the two above.
+
+>     I am now trying to figure out what to propose
+>     for the syntax for inheriting from protected and
+>     task interfaces.  Here are two possibilities:
+>
+>          protected type T is new <interface_list> with ...
+>        or:
+>          protected type T with <interface_list> is ...
+>
+P> The first syntax is the one that is consistent with the Bedford decision.
+
+OK.
+
+>     and then there is the "derived" interface case:
+>
+>          protected interface PI is new <interface_list> with ...
+>         or:
+>          protected interface PI with <interface_list> is ...
+>
+P> I am concerned by the possible lookahead problems for parsers: when you
+P> reach the word "interface", you don't know if it's a keyword or an
+P> identifier.  Furthermore, this syntax is inconsistent with the interface
+P> composition syntax above.
+
+Well, there really isn't any ambiguity, provided you are
+willing to look ahead a bit.  I believe Vincent was more worried
+about conceptual ambiguity.  However, I now believe that
+if we do decide to have non-reserved keywords, then we must
+not worry about conceptual ambiguity, but rather rely on
+programmers to have good sense.  In all of our proposals it
+is possible to make things look funny by using the non-reserved
+keyword as an identifier in the same construct where the
+non-reserved keyword is usable as a keyword.
+
+>     Good point.  I think here we would disallow the
+>     use of "Interface" as the name of a singleton protected
+>     (or task) object, even if interface is a non-reserved keyword.
+>     That seems like an acceptable incompatibility.
+>
+P> This doesn't make sense at all. ...
+
+I agree with you.  We need to accept that the non-reserved
+keyword proposal is subject to the possibility of (intentional?)
+confusion, but so be it.  As you point out, it is solely
+a compatibility technique, so introducing incompatibilities
+*and* non-reserved keywords makes little or no sense.
+
+I also realized after I replied that "protected type interface Blah is ..."
+has exactly the same problem.  That is, "protected type Interface is ..."
+would be a type, whereas "protected type interface Blah is ..."
+would be an interface.
+
+There also would be nothing preventing someone from writing
+"type Interface is interface;" or, perhaps worse,
+"type Interface is tagged;" and other weird-o combinations.
+
+P> The sole purpose of unreserved keywords
+P> is to avoid incompatibilities.  As you know, unreserved keywords are
+P> already a contentious issue.  Unreserved keywords with incompatibilities
+P> are sure to be shot down at the WG9 level.  For my part, I am going to
+P> oppose any AI that has such a blatant incompatibility anyway.
+
+I hear you.  The proposal does *not* have these incompatibilities.
+They appeared only in my quick, and ill-conceived I realize now,
+response to Vincent.
+
+You made no comment on the idea of using "interface" as a
+*substitute* for the word "type" in the syntax.  Any
+comments on that?
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Monday, September 29, 2003  5:43 AM
+
+> This doesn't make sense at all.  The sole purpose of unreserved keywords
+> is to avoid incompatibilities.  As you know, unreserved keywords are
+> already a contentious issue.  Unreserved keywords with incompatibilities
+> are sure to be shot down at the WG9 level.  For my part, I am going to
+> oppose any AI that has such a blatant incompatibility anyway.
+
+The potential confusion between "Interface is" and "interface Mumble is"
+is no big deal, in my opinion.  If you get it wrong, you get a
+compile-time error message, which is relatively harmless.
+
+Useful compiler options would be to warn about uses of unreserved
+keywords as identifiers, or to treat them as reserved words.
+Let's leave that sort of thing to compiler options.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Monday, September 29, 2003  7:49 AM
+
+> OK, that makes me feel better.
+> Though I frankly couldn't remember which we settled
+> on.
+
+That's why we have meeting minutes.  They contain really useful
+information, and are make very pleasurable reading, so I think you
+should look at them more often. ;-)
+
+> >          protected interface PI is new <interface_list> with ...
+>
+> Well, there really isn't any ambiguity, provided you are
+> willing to look ahead a bit.
+
+You're right of course, and from that perspective it is quite different
+from the ambiguity that Vincent pointed out (and which we must avoid at
+all costs).  However, I am still concerned that this could wreak havoc
+in our LALR(1) parser.
+
+> There also would be nothing preventing someone from writing
+> "type Interface is interface;" or, perhaps worse, "type
+> Interface is tagged;" and other weird-o combinations.
+
+And we should ignore such oddities.  Yes, you can write really bizarre
+Ada code if you try hard enough, but programmers who write code that way
+get what they deserve.  We should be concerned about helping readability
+for folks who write reasonable code.
+
+> You made no comment on the idea of using "interface" as a
+> *substitute* for the word "type" in the syntax.  Any
+> comments on that?
+
+I don't like the idea of using "interface" as a _substitute_ for "type",
+because I would like to see the word "type" whenever we declare a type.
+That seems like a useful readability invariant.  However, if you look at
+the Bedford minutes, you'll see:
+
+"Pascal suggests: interface type I2 is new I1 and I2 and I0;"
+
+So I am not opposed to moving "interface" at the beginning of the
+declaration.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, September 29, 2003  8:42 AM
+
+> I am concerned by the possible lookahead problems for parsers: when you
+> reach the word "interface", you don't know if it's a keyword or an
+> identifier.  Furthermore, this syntax is inconsistent with the interface
+> composition syntax above.=20
+
+A little lookahead limited to a few tokens is no big deal, if necessary
+the lexer can do this if you are stuck with a parser with no lookahead
+capability. I would not distort designs too much at this level of concern.
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Monday, September 29, 2003  2:40 PM
+
+> That's why we have meeting minutes.  They contain really useful
+> information, and are make very pleasurable reading, so I think you
+> should look at them more often. ;-)
+
+Yes, they're at least as amusing as the comics in The Boston Globe.
+Perhaps I should start reading these minutes to my 10-year-old son at
+bed time, instead of the Isaac Asimov robot stories he demands these
+days.
+
+> > >          protected interface PI is new <interface_list> with ...
+> >
+> > Well, there really isn't any ambiguity, provided you are
+> > willing to look ahead a bit.
+>
+> You're right of course, and from that perspective it is quite different
+> from the ambiguity that Vincent pointed out (and which we must avoid at
+> all costs).  However, I am still concerned that this could wreak havoc
+> in our LALR(1) parser.
+
+Seems like you could make it work.  I mean, at least the *lexer* can
+look ahead?
+
+> > There also would be nothing preventing someone from writing
+> > "type Interface is interface;" or, perhaps worse, "type
+> > Interface is tagged;" and other weird-o combinations.
+
+..or "type Untagged_Nonlimited is tagged limited..."
+
+> And we should ignore such oddities.  Yes, you can write really bizarre
+> Ada code if you try hard enough, but programmers who write code that way
+> get what they deserve.  We should be concerned about helping readability
+> for folks who write reasonable code.
+
+I'll get up on my high horse now (basically agreeing with Pascal).  My
+language design principle is *not* "Punish those who make bad programs."
+My language design principle is: "Make it easy to make good programs!"
+The former is futile.  The latter is hard work, but it's our job.
+
+[Editor's note: Most of the following discussion is on the concept of
+unreserved keywords, and is filed there (in AI-284).]
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent