CVS difference for ais/ai-40217.txt

Differences between 1.2 and version 1.3
Log of other versions for file ais/ai-40217.txt

--- ais/ai-40217.txt	2003/02/01 04:40:34	1.2
+++ ais/ai-40217.txt	2003/02/05 21:45:39	1.3
@@ -7180,6 +7180,26 @@
 
 *************************************************************
 
+From: Robert A. Duff
+Sent: Saturday, February  1, 2003  9:08 PM
+
+No, not "dead on arrival" at all.  It is, perhaps, the simplest solution
+proposed so far.  All I ask is that the Padua meeting come up with a
+clear ARG-approved vote for *something* to send along to WG9.  Perhaps
+with a strong admonishment not to nitpick, along the lines of Randy's
+"We have to have a solution to mutually dependent types in the
+Amendment."
+
+In support of Tucker's proposal: All well-written Ada 95 programs have a
+(mostly empty) parent package lying around.  The "type C.T" can always
+be put there, without damaging clients.  In legacy Ada 83 programs, the
+parent is Standard, and user's can't edit that.  But Tucker showed how
+to use renaming tricks to get around that, still without damaging
+clients.  Either way, there's never a need to totally restructure the
+package hierarchy to introduce mutually-dependent types.
+
+*************************************************************
+
 From: Tucker Taft
 Sent: Friday, January 31, 2003  9:06 AM
 
@@ -7268,4 +7288,512 @@
 hierarchy.
 
 *************************************************************
+
+From: Robert Dewar
+Sent: Saturday, February  1, 2003  9:18 PM
+
+> In support of Tucker's proposal: All well-written Ada 95 programs have a
+> (mostly empty) parent package lying around.  The "type C.T" can always
+> be put there, without damaging clients.  In legacy Ada 83 programs, the
+> parent is Standard, and user's can't edit that.  But Tucker showed how
+> to use renaming tricks to get around that, still without damaging
+> clients.  Either way, there's never a need to totally restructure the
+> package hierarchy to introduce mutually-dependent types.
+
+
+I disagree with this claim. You can't just make a style statement like
+that without some real evidence of consensus. I see none. OK, so Bob
+Duff says
+
+a) almost all existing Ada 95 programs are badly written
+
+b) we don't care about programs that are badly written
+
+c) our proposal is only for well written programs
+
+This is not the way to get a proposal approved. I very much doubt that WG9
+can be persuaded by an argument that says:
+
+a) we have a solution to the mutual types problem
+b) it's not really right, and we are not happy with it
+c) but we have to have something, so you should approve it anyway.
+
+The concentration must remain on getting a solution that has real
+consensus technically at the ARG and grass roots level, and only
+then does it make sense to take something to WG9.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, February  1, 2003  9:36 PM
+
+Bob said:
+
+> In support of Tucker's proposal: All well-written Ada 95
+> programs have a (mostly empty) parent package lying around.
+
+Oh-oh. Those are fighting words, 'cause they imply that every line of Ada 95
+code that's I've ever written is not "well-written Ada 95". There is no such
+package in Claw, or CBuild, or AdaServe, or anything else I've written.
+
+That's due, in large part, to the fact that I care about the names of things
+for the use-adverse. The names in Claw are too long the way it is, adding
+another level just to meet someone's idea of good style is ridiculous.
+
+Saying that you can use "renaming tricks" is fine, but my style is to use
+those only for compatibility with legacy code. In new code, I always use the
+full name. Case in point, I always use Ada.Text_IO, never Text_IO. An extra
+level of packages means that the names are even harder to read and write. So
+I use them only when it is necessary to the design.
+
+Having the language enforce someone's idea of good style (especially one not
+shared by many of us!) is a very bad idea.
+
+*************************************************************
+
+From: Robert A. Duff
+Sent: Saturday, February  1, 2003 10:01 PM
+
+> > In support of Tucker's proposal: All well-written Ada 95 programs have a
+> > (mostly empty) parent package lying around.  The "type C.T" can always
+> > be put there, without damaging clients.  In legacy Ada 83 programs, the
+> > parent is Standard, and user's can't edit that.  But Tucker showed how
+> > to use renaming tricks to get around that, still without damaging
+> > clients.  Either way, there's never a need to totally restructure the
+> > package hierarchy to introduce mutually-dependent types.
+>
+> I disagree with this claim.
+
+OK, let me state it differently:
+
+There are two cases: you have a parent lying around (that's the style I
+usually like) or you don't.  If you do, there's a clear place to put the
+incomplete type (in the parent of wherever the type already is).  If you
+don't, the renaming tricks work seemlessly.  Either way, there's no
+problem for clients.
+
+>...You can't just make a style statement like
+> that without some real evidence of consensus. I see none. OK, so Bob
+> Duff says
+>
+> a) almost all existing Ada 95 programs are badly written
+
+OK, I back off on that.
+
+> b) we don't care about programs that are badly written
+
+I never said that.  I explicitly pointed out that those programs can
+easily deal with it.  (I admit "badly written" was a poorly chosen value
+judgement.)  My point was that there's no problem for those programs
+that choose that flat-namespace style.
+
+> c) our proposal is only for well written programs
+
+Not at all.  Please read my comment again: you'll see that the proposal
+works fine for both styles, which is the goal.  Note my claim, "Either
+way, there's never a need to totally restructure the package hierarchy
+to introduce mutually-dependent types."
+
+*************************************************************
+
+From: Robert A. Duff
+Sent: Saturday, February  1, 2003 10:12 PM
+
+Randy said:
+
+> Bob said:
+>
+> > In support of Tucker's proposal: All well-written Ada 95
+> > programs have a (mostly empty) parent package lying around.
+>
+> Oh-oh. Those are fighting words,
+
+I didn't *mean* them to be "fighting words".  ;-)
+
+>... 'cause they imply that every line of Ada 95
+> code that's I've ever written is not "well-written Ada 95". There is no such
+> package in Claw, or CBuild, or AdaServe, or anything else I've written.
+
+Heh?  I thought everthing was under a parent CLAW or CBuild or whatever.
+
+The point is that if you happen to have a parent already, that's a
+reasonable place for the incomplete type decl.  No big deal.  If you
+don't, it's *still* no big deal because of package renamings.
+
+...
+> Having the language enforce someone's idea of good style (especially one not
+> shared by many of us!) is a very bad idea.
+
+I completely agree -- no enforcing of style is intended here.
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, February  1, 2003  9:56 PM
+
+I just looked at the implementation implications of Tucker's "type C.T"
+proposal in Janus/Ada.
+
+Janus/Ada is a syntax-directed compiler in the classic style (as it started
+as an class project, and the textbook was the dragon book). That means a
+syntax change (as opposed to addition) can have ripple effects throughout
+the compiler.
+
+The syntax that the compiler uses for incomplete types is currently:
+    Type_Head discrim_option SEMICOLON
+where Type_Head is
+    TYPE IDENTIFIER
+
+In order to implement Tucker's syntax, we'd have to change Type_Head to:
+    TYPE IDENTIFIER DOT IDENTIFIER |
+    TYPE IDENTIFIER
+
+Type_Head is used in all type declarations, including generic formal types.
+(There is a comment which says that the grammar is not LALR(1) if that is
+not done).
+
+The processing done for Type_Head is to enter an empty, dummy type into the
+symbol table. Discrim_Option "knows" where this is, and puts the
+discriminants into that type.
+
+This means that this change would have two major impacts on the compiler:
+    All types (including formal types) would have to be able to do
+declarations into these "ghost" packages. An error would be generated, of
+course, but we can't stop processing the program for such a trivial
+appearing error. And we have to do something sensible (not crash!) in any
+case, even though the program is illegal. A large part of the bugs that we
+have to fix are errors in error handling. This is on top of the semantic
+check itself.
+    The declarations of discriminants would have to be rewritten to support
+insertion into a ghost package rather than the current declaration location.
+It might be possible to "fool" this code into writing into a ghost package,
+but then that would have to be undone at every possible type declaration.
+
+In summary, this looks like a bigger change than type stubs.
+
+Indeed, if my proposed simplification to the completion rules was adopted, I
+don't believe that any change to type matching or to type declarations or
+use would be needed. The only real change (besides actually implementing the
+declaration) would be to context clause processing to "hook" the stub to the
+completion (which is necessary in Tucker's proposal as well as original type
+stubs).
+
+BTW, I mentioned yesterday that a post-compilation rule was necessary to
+make that idea work. That's not actually true (although it might still be a
+good idea to have one). The only impact if the completion did not with the
+package containing the stub would be that the completion would never match
+the stub (no matter what was withed elsewhere). That seems tolerable to me,
+but since it would probably cause mysterious errors, a post-compilation
+check is better. Note that the post-compilation check would have to not be
+triggered if there was no completion at all.
+
+I'll try to write up the wording for this, but probably not until I'm on my
+way to the meeting.
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Monday, February 3, 2003  1:55 PM
+
+Randy Brukardt wrote:
+>
+> I just looked at the implementation implications of Tucker's "type C.T"
+> proposal in Janus/Ada.
+>
+> Janus/Ada is a syntax-directed compiler in the classic style (as it started
+> as an class project, and the textbook was the dragon book). That means a
+> syntax change (as opposed to addition) can have ripple effects throughout
+> the compiler.
+
+I sympathize here.  Our compiler does essentially all semantic analysis on
+the fly while parsing.  We don't build up syntax trees for anything
+much bigger than an expression, and we do the first "pass" of overload
+resolution while building up expression trees.
+
+> The syntax that the compiler uses for incomplete types is currently:
+>     Type_Head discrim_option SEMICOLON
+> where Type_Head is
+>     TYPE IDENTIFIER
+>
+> In order to implement Tucker's syntax, we'd have to change Type_Head to:
+>     TYPE IDENTIFIER DOT IDENTIFIER |
+>     TYPE IDENTIFIER
+>
+> Type_Head is used in all type declarations, including generic formal types.
+> (There is a comment which says that the grammar is not LALR(1) if that is
+> not done).
+
+I presume that is not the only place where the grammar is not LALR(1)!
+
+> The processing done for Type_Head is to enter an empty, dummy type into the
+> symbol table. Discrim_Option "knows" where this is, and puts the
+> discriminants into that type.
+>
+> This means that this change would have two major impacts on the compiler:
+>     All types (including formal types) would have to be able to do
+> declarations into these "ghost" packages. An error would be generated, of
+> course, but we can't stop processing the program for such a trivial
+> appearing error. And we have to do something sensible (not crash!) in any
+> case, even though the program is illegal. A large part of the bugs that we
+> have to fix are errors in error handling. This is on top of the semantic
+> check itself.
+>     The declarations of discriminants would have to be rewritten to support
+> insertion into a ghost package rather than the current declaration location.
+> It might be possible to "fool" this code into writing into a ghost package,
+> but then that would have to be undone at every possible type declaration.
+
+Would you really need to undo anything?  It seems that you would simply allow
+any sort of type in a "ghost" package, but of course give some kind
+of error message if it turns out not to be incomplete, because that is
+the "arbitrary" restriction that the silly ARG imposed.  You would
+then also be ready for future enhancements to the language ;-).
+
+> In summary, this looks like a bigger change than type stubs.
+
+It is of course impossible for anyone outside RR to evaluate that,
+but I can say that for our compiler, dealing with the "availability"
+rules associated with type stubs was looking like a brand new kettle of fish.
+
+> ...
+> BTW, I mentioned yesterday that a post-compilation rule was necessary to
+> make that idea work. That's not actually true (although it might still be a
+> good idea to have one). The only impact if the completion did not with the
+> package containing the stub would be that the completion would never match
+> the stub (no matter what was withed elsewhere). That seems tolerable to me,
+> but since it would probably cause mysterious errors, a post-compilation
+> check is better. Note that the post-compilation check would have to not be
+> triggered if there was no completion at all.
+
+It would seem that if you go this far, then you should only allow one stub
+in the program.  Allowing multiple stubs seems like gratuitous complexity
+in the matching rules.  Was it your intent to allow only one stub,
+and require that the stub be visible (due to "withing" the enclosing
+package or a renaming thereof) at the point of the completing type declaration?
+
+> I'll try to write up the wording for this, but probably not until I'm on my
+> way to the meeting.
+
+**************************************************************
+
+From: Pascal Leroy
+Sent: Monday, February  3, 2003  4:20 AM
+
+> There seems to be some feeling that type stubs
+> were almost right, and we should either leave
+> them as is, or add some kind of special context
+> clause such as "separate with ..." and be done with it.
+
+I am one of the people who thought that type stubs were "almost right" and I
+must admit that I am getting more and more uncomfortable with this proposal.  I
+think that your "philosophizing" nicely summarizes the issues, and I only
+wished you wrote it earlier (it's only a few days before the meeting...).
+
+> 1) Type stubs look and feel like an add-on to the language.
+
+Agreed, but then so do your latest proposals regarding package prefixes and
+"type C.T".  Other than shuffling the keywords around, I don't see that they
+integrate much better in the existing language.  Actually, other that package
+abstracts, all the proposals look like warts.
+
+> 2) Type stubs are not necessarily "seen" by the type completer.
+
+You're right, this might be a serious implementation problem, although not
+necessarily more complicated than having three-part types or a new kind of
+compilation unit.
+
+> 3) Type stubs seems to require a particular "idiom" of use
+>     that makes it seem clear that some kind of package "prefix"
+>     or "abstract" is what we *really* wanted but couldn't somehow
+>     bring ourselves to provide.
+
+Yes, it's always suspicious when we have to recommend a particular idiom to
+achieve some effect that should be straightforwardly supported by the language.
+See for instance the idioms to "simulate" multiple inheritance or downward
+closures in Ada 95.
+
+> 4) Type stubs have the unfortunate situation where the
+>     same type has two different fully expanded names.
+
+I cannot get too excited about this problem.  At the implementation level you
+have to match up distinct type declarations, whatever the model, so it doesn't
+bother me too much that they have distinct expanded names.
+
+> b) package prefix/abstract feels like a big change, requiring a new
+>     kind of program unit, a new kind of context clause, and non
+>     obvious rules about what part of the parent unit a child
+>     prefix/abstract can see.  Admittedly, the package prefix is
+>     probably the most powerful and flexible.
+
+I think that package abstract is in some sense the most logical choice, and
+that it's the approach we would choose if the year were 1980 and we were not
+concerned about disrupting implementations.
+
+> c) "type C.T;" seems like a natural outgrowth of two basic facts:
+>      i) the incomplete type declaration is the fundamental way
+>         of supporting mutually dependent types in Ada, but it
+>         is limited to only working within a single package spec;
+>      ii) child packages are the fundamental way of splitting a large
+>         abstraction into smaller, more manageable parts, but they are
+>         limited in that mutually dependent types cannot cross
+>         these pieces of the abstraction.
+
+I am sorry, I don't see the connection.  Both (i) and (ii) are true statements,
+but I don't understand why you absolutely want to tie a solution to the problem
+of mutually-dependent types to child units.  To me this fails your criteria #1
+above, and using child units for that purpose looks totally awkward.
+
+> The major objection to
+> the more flexible incomplete type declaration seems to be that
+> it might not just "drop" into existing code.
+
+As far as I am concerned there is also an aesthetical reason, which I find hard
+to convey, but I feel strongly about it: child units are not the proper
+construct to solve the problem at hand.
+
+*************************************************************
+
+From: Tucker Taft
+Sent: Monday, February 3, 2003  2:35 PM
+
+Pascal Leroy wrote:
+> ...
+> > c) "type C.T;" seems like a natural outgrowth of two basic facts:
+> >      i) the incomplete type declaration is the fundamental way
+> >         of supporting mutually dependent types in Ada, but it
+> >         is limited to only working within a single package spec;
+> >      ii) child packages are the fundamental way of splitting a large
+> >         abstraction into smaller, more manageable parts, but they are
+> >         limited in that mutually dependent types cannot cross
+> >         these pieces of the abstraction.
+>
+> I am sorry, I don't see the connection.  Both (i) and (ii) are true statements,
+> but I don't understand why you absolutely want to tie a solution to the problem
+> of mutually-dependent types to child units.  To me this fails your criteria #1
+> above, and using child units for that purpose looks totally awkward.
+
+In my personal view of the world, if two types are mutually dependent,
+they are in some sense part of the "same" abstraction,
+or at least parts of two closely related abstractions.
+And in this same world view, all parts of a single abstraction should be grouped
+together within a single part of the program's namespace.
+
+Ada 95 pushes the programmer this way since generally
+parts of the same abstraction all need visibility
+on some common bit of hidden information, such as a private
+part of some package.  We considered the (dreaded) "with private"
+approach to "opening up the Kimono" of a private type,
+and rejected it in the Ada 9X process.  We concluded
+that there were many advantages to keeping visibility
+on hidden information within a well defined part of the namespace.
+
+This is the reason I see support for mutual dependence
+only between packages in the same package hierarchy as
+a perfectly acceptable limitation.  Combined with the
+ability to hide this package hierarchy using renaming,
+in the situations where it is undesirable to tie
+these packages together in the namespace, it seemed like
+a good, simple (even elegant? ;-) solution to the problem.
+
+> > The major objection to
+> > the more flexible incomplete type declaration seems to be that
+> > it might not just "drop" into existing code.
+>
+> As far as I am concerned there is also an aesthetical reason, which I find hard
+> to convey, but I feel strongly about it: child units are not the proper
+> construct to solve the problem at hand.
+
+Unfortunately, design issues often depend on our intuitions
+about what makes sense and what doesn't.  Sometimes our
+intuitions line up, and sometimes they don't.  With this
+one, we aren't doing a lot of lining up ;-(.
+
+I think we also are being reminded why design by committee is so hard,
+if the entire committee is committed to producing an excellent,
+intuitively obvious, elegant, aesthetic, implementable design.
+
+**************************************************************
+
+From: Tucker Taft
+Sent: Monday, February 3, 2003  8:16 PM
+
+Tucker replied to me:
+
+> > Type_Head is used in all type declarations, including generic formal types.
+> > (There is a comment which says that the grammar is not LALR(1) if that is
+> > not done).
+>
+> I presume that is not the only place where the grammar is not LALR(1)!
+
+Our grammar is LALR(1) of course; the comment just was there to tell me not
+to bother trying to separate these cases, because it won't work. I know that
+otherwise, I'd try to "improve" the grammar to eliminate these useless
+cases, and waste a lot of time.
+
+There is no obvious relationship between our compiler's grammar and the one
+in the RM. (For the obvious reasons).
+
+> >     The declarations of discriminants would have to be rewritten to support
+> > insertion into a ghost package rather than the current declaration location.
+> > It might be possible to "fool" this code into writing into a ghost package,
+> > but then that would have to be undone at every possible type declaration.
+>
+> Would you really need to undo anything?  It seems that you would simply allow
+> any sort of type in a "ghost" package, but of course give some kind
+> of error message if it turns out not to be incomplete, because that is
+> the "arbitrary" restriction that the silly ARG imposed.  You would
+> then also be ready for future enhancements to the language ;-).
+
+You'd have to "undo" declaring into the ghost package, because if you
+didn't, everything declared after it would go into the ghost. That would be
+bad, even for an illegal program, because it would cause cascading errors.
+And that would have to be done in every kind of type declaration.
+
+> > In summary, this looks like a bigger change than type stubs.
+>
+> It is of course impossible for anyone outside RR to evaluate that,
+> but I can say that for our compiler, dealing with the "availability"
+> rules associated with type stubs was looking like a brand new
+> kettle of fish.
+
+With the simplified rules you and I have been discussing, I believe that
+type stubs (not including tagged incomplete) would take 4 hours of work.
+Period. One mildly messy routine to run at the end of context clause
+processing (to look for completions of any stubs loaded), and one rather
+simple post-compilation check. Nothing for "availablility" at all, it
+follows from standard type matching and visibility. It'll take longer to
+figure out where the routines go than to write and test them.
+
+> > ...
+> > BTW, I mentioned yesterday that a post-compilation rule was necessary to
+> > make that idea work. That's not actually true (although it might still be a
+> > good idea to have one). The only impact if the completion did not with the
+> > package containing the stub would be that the completion would never match
+> > the stub (no matter what was withed elsewhere). That seems tolerable to me,
+> > but since it would probably cause mysterious errors, a post-compilation
+> > check is better. Note that the post-compilation check would have to not be
+> > triggered if there was no completion at all.
+>
+> It would seem that if you go this far, then you should only allow one stub
+> in the program.  Allowing multiple stubs seems like gratuitous complexity
+> in the matching rules.  Was it your intent to allow only one stub,
+> and require that the stub be visible (due to "withing" the enclosing
+> package or a renaming thereof) at the point of the completing
+> type declaration?
+
+Not on Saturday. Thinking about that yesterday and this morning, I concluded
+that it would be better to restrict to one stub per type (otherwise, you
+have the stub-stub matching rules, or they don't match, which is weird). It
+isn't critical, but it would avoid surprises.
+
+Anyway, this idea may be OBE. Since I thought that your proposal was too
+much work to implement, Pascal decided to propose one that would be ten
+times more work. :-)
+
+**************************************************************
+
+**************************************************************
+
+**************************************************************
+
+**************************************************************
 

Questions? Ask the ACAA Technical Agent