CVS difference for ais/ai-00262.txt

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

--- ais/ai-00262.txt	2003/01/03 00:01:35	1.15
+++ ais/ai-00262.txt	2003/01/24 04:14:27	1.16
@@ -3071,3 +3071,673 @@
 via mail.
 
 ****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, December 21, 2002  1:33 PM
+
+> That would prevent using type stubs in private parts. One of the big
+> advantages of type stubs over the original "with type" is that type stubs
+> can be made to be private. That let's you declare a handle to them without
+> exposing the actual access type to the world:
+
+Incidentally, I find it a serious flaw that there is no separate context
+clause for the private part (for my programming, a much more serious flaw
+than the concern about mutually recursive types). Is this issue being
+addressed at all.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, December 21, 2002  2:36 PM
+
+That's the point of the "private with" clause, see AI-262, already approved
+by WG9. A fine candidate for a trial implementation in my view. :-)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, December 21, 2002  2:42 PM
+
+Ah yes, sorry, forgot about that. Indeed that is indeed a fine candidate
+for trial implementation. What we are planning to do in GNAT is to have
+the private part in a separate file, and then that file is where the
+private with's would go.
+
+We constantly find it annoying both from an IPR point of view and multiple
+implementation point of view to have the private part in the same file as
+the spec. For one thing it leads to IPR statements like:
+
+-- This specification is derived from the Ada Reference Manual for use with --
+-- GNAT. The copyright notice above, and the license provisions that follow --
+-- apply solely to the  contents of the part following the private keyword. --
+
+:-)
+
+And indeed I agree that a variant of this is needed for the type stubs case.
+
+****************************************************************
+
+From: David Emery
+Sent: Saturday, December 21, 2002  3:09 PM
+
+Given the intended use of Java, I'm amazed that this isn't a bigger problem
+in that community.  If I were king, the first thing I'd add to Java is
+named parameter notation.  Pure syntactic sugar with tremendous benefits
+for readability and maintainability.  Separate specs and bodies would be
+#2 on my list, followed by enumeration types, strongly typed scalars, and
+finally some way to raise the level of the concurrency primitives to that
+approaching Ada95...
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Saturday, December 21, 2002  3:42 PM
+
+> We constantly find it annoying both from an IPR point of view and multiple
+> implementation point of view to have the private part in the same file as
+> the spec.
+
+I agree.
+
+What will the syntax look like?
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, December 21, 2002  3:52 PM
+
+Haven't decided yet. Note that we can choose any "syntax" we like because
+tehcnically it is merely a source representation issue (i.e. we have a funny
+source representation for private parts, which is our way of representing
+the standard syntax).
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Saturday, December 21, 2002  4:32 PM
+
+The "obvious" thing would be to split the text just before "private",
+so one file would have:
+
+    with Something;
+    private with Something_Else;
+    package P is
+        type T is private;
+        procedure Mumble(X: T; Y: Something.T);
+
+and the other file would have:
+
+    private
+        type T is new Something_Else.Whatever;
+    end P;
+
+But that's pretty ugly:
+
+    - The "private with" really ought to be in the second file.
+
+    - The lack of "end" in the first file looks silly.
+
+    - There ought to be a way for the reader of the first file to know
+      whether the second one exists.
+
+    - The second file ought to have the package name near the beginning,
+      rather than just on the "end" line.
+
+To honestly claim "merely a source representation issue", I think you
+have to specify an automatable way of translating to the "real" syntax.
+Preferably, a *simple* translation.
+
+I wonder if we could arrive at an agreement on this "source rep" that
+could be implemented in all the compilers?  The ARG need not be
+officially involved, since it's "merely a source representation issue".
+It seems trivial to implement.  And if we all do it the same way, that's
+good for Ada, and what's good for Ada is good for all Ada vendors...
+(I like to think that our competition is other languages, not other Ada
+compiler vendors...)
+
+It seems obvious (with 20-20 hindsight) that the private part ought to
+be in a separate file from the visible part.  Too bad the syntax was not
+originally designed with this in mind.
+
+Another issue that comes to mind is that if the visible part of a
+library package has nested packages/tasks/protected types, then it would
+be desirable to move those nested private parts into the second file,
+too.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Saturday, December 21, 2002  5:16 PM
+
+> To honestly claim "merely a source representation issue", I think you
+> have to specify an automatable way of translating to the "real" syntax.
+> Preferably, a *simple* translation.
+
+Sure, but all the glithces you mention are easily corrected under these
+criteria.
+
+> I wonder if we could arrive at an agreement on this "source rep" that
+> could be implemented in all the compilers?  The ARG need not be
+> officially involved, since it's "merely a source representation issue".
+> It seems trivial to implement.  And if we all do it the same way, that's
+> good for Ada, and what's good for Ada is good for all Ada vendors...
+> (I like to think that our competition is other languages, not other Ada
+> compiler vendors...)
+
+I think that would be nice (to agree on this format).
+
+> Another issue that comes to mind is that if the visible part of a
+> library package has nested packages/tasks/protected types, then it would
+> be desirable to move those nested private parts into the second file,
+> too.
+
+I think that's over complex over kill :-)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Saturday, December 21, 2002  12:48 AM
+
+To me, the "obvious" syntax would be something closer to:
+
+package P is
+     ...
+private is separate;
+end P;
+
+
+package private P is
+    ....
+end P;
+
+The syntax for the separate private part is using "private"
+somewhat the way "body" is used.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Sunday, December 22, 2002  7:17 AM
+
+That seems fine to me, and is close to one of the forms we had considered
+in particular the "private is separate" seems natural. The private with's
+also go in the private part file of course.
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Monday, December 23, 2002  11:44 AM
+
+Robert Dewar wrote:
+> >
+> > That's the point of the "private with" clause, see AI-262, already approved
+> > by WG9. A fine candidate for a trial implementation in my view. :-)
+>
+> Ah yes, sorry, forgot about that. Indeed that is indeed a fine candidate
+> for trial implementation. What we are planning to do in GNAT is to have
+> the private part in a separate file, and then that file is where the
+> private with's would go.
+
+I believe that AI-262 as written is not particularly conducive to
+shuffling the private with's to a separate file, since the private with's
+have semantic effect (albeit minor) in the visible part of the package.
+
+If ACT seriously intends to implement private parts in a separate file,
+then other vendors would likely do so as well, making private with's
+of AI 262 a deprecated feature.
+
+My understanding is that the premise of AI 262 and AI 217 is that it is
+too much implementation burden to support breaking a package spec into
+separate files, each with their own context clause.  If this is really
+not the case, then AI 217 should probably be solved by breaking the
+visible part of a package into separate files, each with their own
+context clause, consistent with the ACT plan for separate private parts.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, December 23, 2002  11:53 AM
+
+> I believe that AI-262 as written is not particularly conducive to
+> shuffling the private with's to a separate file, since the private with's
+> have semantic effect (albeit minor) in the visible part of the package.
+>
+> If ACT seriously intends to implement private parts in a separate file,
+> then other vendors would likely do so as well, making private with's
+> of AI 262 a deprecated feature.
+
+This is confused. Putting these in a separate file is simply a matter of
+source representation, it has no effect whatever on the semantics as far
+as I am concerned. In other words, the parser reassembles the canonical
+file from the two parts before anything else happens (note that indeed we
+can in practice put perfectly ordinary with's in the private part file, but
+it's neater with the private with).
+
+> My understanding is that the premise of AI 262 and AI 217 is that it is
+> too much implementation burden to support breaking a package spec into
+> separate files, each with their own context clause.  If this is really
+> not the case, then AI 217 should probably be solved by breaking the
+> visible part of a package into separate files, each with their own
+> context clause, consistent with the ACT plan for separate private parts.
+
+This seems confused. Files are an implementation artifact, there is no such
+concept in the RM.
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Monday, December 23, 2002  12:06 PM
+
+> I believe that AI-262 as written is not particularly conducive to
+> shuffling the private with's to a separate file, since the private with's
+> have semantic effect (albeit minor) in the visible part of the package.
+
+I don't think it's a big deal.  You have to run the parser on *both*
+files before doing semantic analysis on them.  After parsing both,
+analyze the with clauses from the visible-part file, then the with
+clauses from the private-part file, then the rest of the vis part,
+then the rest of the private part.  A bit odd, perhaps, but not hard to
+implement.
+
+It seems important that splitting a package spec into two files should
+not change its semantics.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, December 23, 2002  12:11 PM
+
+Exactly, and indeed likely our initial implementation will just use normal
+with clauses, since we have not bothered with private with yet, and have
+no plans to do so in the near future.
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Monday, December 23, 2002  12:16 PM
+
+> This is confused. Putting these in a separate file is simply a matter of
+> source representation, it has no effect whatever on the semantics as far
+> as I am concerned. In other words, the parser reassembles the canonical
+> file from the two parts before anything else happens (note that indeed we
+> can in practice put perfectly ordinary with's in the private part file, but
+> it's neater with the private with).
+
+It sounds like you intend to restrict the with clauses on the private part
+of package A from depending on a unit B that in turn depends on A.  But
+this seems to be an unnececessary restriction.  Certainly the with clauses
+allowed on subunits don't have such a restriction.
+
+The intent of implementation freedom of source representation is not for
+purposes such as this.  Abusing this implementation freedom creates
+unportable code.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, December 23, 2002  12:32 PM
+
+> > It sounds like you intend to restrict the with clauses on the private part
+> > of package A from depending on a unit B that in turn depends on A.  But
+> > this seems to be an unnececessary restriction.  Certainly the with clauses
+> > allowed on subunits don't have such a restriction.
+
+No, we do not intend any such restrictions, this is simply a matter of
+lexical separation of IPR concerns, and also to help with separation of
+target dependent private parts, nothing more, nothing less. Yes, you can
+propose something fancier. I am not sure it is worth it.
+
+> The intent of implementation freedom of source representation is not for
+> purposes such as this.  Abusing this implementation freedom creates
+> unportable code.
+
+No more unportable than putting multiple units in a single file. In either
+case you need a (trivial) tool to convert from one form to the other for
+export. GNAT for instance cannot digest multiple units in one file (which
+is of course *purely* a source representation issue) and has a tool to
+split incoming non-portable code from other compilers :-)
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Monday, December 23, 2002  1:06 PM
+
+This seems confused.  If the private part of A depends on B which depends
+on A, then the resulting transformation using "private with" would not be
+legal due to circularity between package specs.
+
+   package A is
+   ...1
+   private is separate;
+   end A;
+
+   with A;
+   package B is
+   ...2
+   end B;
+
+   with B;
+   package private A is
+   ...3
+   end A;
+
+presumably transforms to:
+
+   private with B;      -- illegal circularity
+   package A is
+   ...1
+   private
+   ...3
+   end A;
+
+   with A;
+   package B is
+   ...2
+   end B;
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, December 23, 2002  1:16 PM
+
+no that's not the transformation, if you use a with clause, it would
+transform to a with clause.
+
+Please understand, the separation of canonical represeantation, whose
+syntax and semantics is well understood into two files is a purely lexical
+issue, the two files get reassembled into canonical form before they are
+processed.
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Monday, December 23, 2002  1:10 PM
+
+Dan said:
+
+> > > It sounds like you intend to restrict the with clauses on the private part
+> > > of package A from depending on a unit B that in turn depends on A.  But
+> > > this seems to be an unnececessary restriction.  Certainly the with clauses
+> > > allowed on subunits don't have such a restriction.
+
+And Robert replied:
+
+> No, we do not intend any such restrictions,
+
+I think Dan is correct in the first sentence: you *do* intend such a
+restriction, since such a restriction already exists in Ada, and your
+intent is a "mere" source-rep thing, not a change in semantics.
+
+Dan is talking about package-spec A with's B, and package-spec B with's
+A.  Surely that will still be an illegal circle, even if the with's
+appear in the private-part file.
+
+Am I missing something?  It seems to me that to claim "source rep",
+then a with appearing in the private-part file must behave identically
+to one appearing in the visible part file (because conceptually, that
+transformation is exactly what happens).
+
+If private parts have their own dependences, separately from the visible
+part, then that would imply that something else can be elaborated in
+between the visible and private parts.  I suspect that would break
+things badly.  The freezing rules, for example, depend on the whole
+package spec being elaborated at once.
+
+I don't think Dan's reference to subunits is relevant: subunits can
+appear only in bodies, and with-clauses only refer to specs.  So moving
+a with clause from a subunit to its parent body cannot introduce a
+cyclic dependence on that *body*.
+
+>... this is simply a matter of
+> lexical separation of IPR concerns, and also to help with separation of
+> target dependent private parts, nothing more, nothing less. Yes, you can
+> propose something fancier. I am not sure it is worth it.
+>
+> > The intent of implementation freedom of source representation is not for
+> > purposes such as this.  Abusing this implementation freedom creates
+> > unportable code.
+
+I agree with Dan here.  But I was hoping to get an informal agreement
+among compiler writers to support the same way of visible/private
+splitting.
+
+> No more unportable than putting multiple units in a single file.
+
+Yeah, that also leads to unportable code.  I think it's unfortunate that
+all compilers don't agree on this point.
+
+>...In either
+> case you need a (trivial) tool to convert from one form to the other for
+> export. GNAT for instance cannot digest multiple units in one file (which
+> is of course *purely* a source representation issue) and has a tool to
+> split incoming non-portable code from other compilers :-)
+
+Right, GNAT is not in violation of the "law" here, but it's still a pain
+to have to use extra tools.  In practice, it's much better to use the
+lowest common denominator supported by all compilers, than to use tools
+to translate from one form to another.
+
+In particular, I wouldn't use separate files for private parts unless I
+had some confidence that most or all compilers would support that
+representation.  Even though it is indeed useful to have that physical
+separation.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, December 23, 2002  1:18 PM
+
+> I think Dan is correct in the first sentence: you *do* intend such a
+> restriction, since such a restriction already exists in Ada, and your
+> intent is a "mere" source-rep thing, not a change in semantics.
+
+What I meant is that there are no additional restrictions of any kind that
+come from the splitting into two files, this is simply a lexical issue.
+
+> Yeah, that also leads to unportable code.  I think it's unfortunate that
+> all compilers don't agree on this point.
+
+Since the standard has nothing whatever to say in this area, why does it
+surprise you. The standard is not in the business of specifying source
+represaentation and never has been.
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Monday, December 23, 2002  1:45 PM
+
+Robert Duff wrote:
+> If private parts have their own dependences, separately from the visible
+> part, then that would imply that something else can be elaborated in
+> between the visible and private parts.  I suspect that would break
+> things badly.  The freezing rules, for example, depend on the whole
+> package spec being elaborated at once.
+
+My suspicion is that it would hardly break things at all, and users would
+insist on eliminating the silly restriction.  Depending on a private type
+before its full type has been seen would be exactly like depending on a
+type stub.
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Monday, December 23, 2002  2:47 PM
+
+> My suspicion is that it would hardly break things at all, and users would
+> insist on eliminating the silly restriction.  Depending on a private type
+> before its full type has been seen would be exactly like depending on a
+> type stub.
+
+    package A is
+        C: constant String;
+    private is separate;
+    end A;
+
+    with A;
+    package B is
+        X: String := A.C;
+    end B;
+
+    private with B; -- Illegal cycle!
+    package private A is
+        C: constant String := X;
+    end A;
+
+It's not clear what the run-time semantics of the above ought to be.
+I claim it should be illegal (and it *is* illegal, if you go the
+route that Robert has been advocating).
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, December 23, 2002  3:08 PM
+
+This most certainly should be illegal. I do not know what it might be
+intended to mean if it were legal!
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Monday, December 23, 2002  3:11 PM
+
+I agree that it should be illegal, but maybe for different reasons.
+
+The declaration of B.X should be illegal as an unallowed use of
+a deferred constant, just as it would be illegal to say:
+
+  package A is
+     C: constant String;
+     X: String := A.C;
+  private
+     C: constant String := X;
+  end A;
+
+Note: in this example, there is only one possible compilation order,
+so it is pretty clear that package B is intended to depend only on the
+visible part of A.  However, that wouldn't always be true in general,
+so we would need to provide some way to indicate that a with clause is
+intended to apply only to a package's visible part.  Otherwise there
+would be cases where legality depended on compilation order.
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Monday, December 23, 2002  3:10 PM
+
+> > I think Dan is correct in the first sentence: you *do* intend such a
+> > restriction, since such a restriction already exists in Ada, and your
+> > intent is a "mere" source-rep thing, not a change in semantics.
+>
+> What I meant is that there are no additional restrictions of any kind that
+> come from the splitting into two files, this is simply a lexical issue.
+
+Dan was suggesting to *remove* an existing restriction, not to add an
+additional one.  Removing restrictions is bad, because it removes the
+pure lexical nature of the transformation.
+
+However, I think there *should* be an additional restriction: If you say
+"with X;" in a private part file, you should not be allowed to refer to
+X in the visible part.  Otherwise, you've defeated the whole readability
+purpose of having with clauses at the front.
+
+Note that you objected to type stubs for the same reason -- you don't
+like referring to some other package without having a with clause up
+front.
+
+> > Yeah, that also leads to unportable code.  I think it's unfortunate that
+> > all compilers don't agree on this point.
+>
+> Since the standard has nothing whatever to say in this area, why does it
+> surprise you. The standard is not in the business of specifying source
+> represaentation and never has been.
+
+It doesn't surprise me; it annoys me.  My point is that the world would
+be a better place if all Ada compilers supported the same source
+representations (including how many comp units you can put in a file,
+file-naming conventions, etc).  I know full well that this is not an RM
+issue.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, December 23, 2002  4:16 PM
+
+That ups the ante in the difficulty of implementation considerably. I
+perfectly well understand that it would be nice-to-have :-)
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Monday, December 23, 2002  4:36 PM
+
+Robert wrote:
+
+> That ups the ante in the difficulty of implementation considerably.
+
+Agreed.  It's essentially the same as implementing "private with".
+In fact, the obvious thing is to say that "private with"s go in the
+private-part file.
+
+If it's too much trouble to implement this "properly", at least
+documentation ought to admonish programmers to be careful.
+
+> ...I perfectly well understand that it would be nice-to-have :-)
+
+Agreed.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, January 17, 2003  5:38 PM
+
+Replying to an old conversation of Bob and Robert's that happened while I
+was away at Christmas:
+
+Bob replying to Robert replying to Bob:
+>>> However, I think there *should* be an additional restriction: If you say
+>>> "with X;" in a private part file, you should not be allowed to refer to
+>>> X in the visible part.  Otherwise, you've defeated the whole readability
+>>> purpose of having with clauses at the front.
+>>>
+>>> Note that you objected to type stubs for the same reason -- you don't
+>>> like referring to some other package without having a with clause up
+>>> front.
+
+>>That ups the ante in the difficulty of implementation considerably. I
+>>perfectly well understand that it would be nice-to-have :-)
+
+>> Agreed.  It's essentially the same as implementing "private with".
+>> In fact, the obvious thing is to say that "private with"s go in the
+>> private-part file.
+
+Well, actually, the obvious thing to say is that any "with"s in the private
+part file are transformed to "private with"s in the transformed file.
+Indeed, I can hardly imagine why you would want any other semantics - you
+certainly don't want withs used in the spec that aren't even on the source.
+
+Now, of course, if some compiler hasn't implemented "private with" yet, then
+there is no real difference. But that shouldn't matter to the
+"transformation" that is behind this. Particularly if we want to agree on it
+as a quasi-standard.
+
+> If it's too much trouble to implement this "properly", at least
+> documentation ought to admonish programmers to be careful.
+
+"private with" is supposed to be dirt-cheap to implement. Because the only
+effect is that certain references are illegal (all other things remaining
+the same, including the visibility of the illegal references), it seems only
+to require a symboltable bit for package declarations, a function to
+determine if the current locality of a reference is not in a private part
+(that is, the rules in AI), and an error message. The function might be a
+bit messy in some implementations, but I doubt it could be too bad; there's
+plenty of other places where you need to figure out whether you're in a
+visible or private part. This shouldn't be more than a few days work,
+including documentation. The separate private part mechanism would be at
+least as much work (most of it going to the tool to create the canonical
+representation, which has to be able to lex Ada source and do at least
+limited parsing). So I don't see much reason to avoid implementing it if
+you're going to going through the greater effort of the separate
+compilation.
+
+****************************************************************
+
+

Questions? Ask the ACAA Technical Agent