CVS difference for ais/ai-00262.txt

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

--- ais/ai-00262.txt	2001/02/23 20:43:09	1.4
+++ ais/ai-00262.txt	2001/03/22 22:24:54	1.5
@@ -1191,6 +1191,79 @@
 ****************************************************************
 
 From: Robert A Duff
+Sent: Saturday, February 24, 2001 4:29 PM
+
+> I think this somewhat defeats the purpose of the "in body."
+
+I don't see how the mere existence of such a pragma defeats the
+purpose.  You don't have to use it.
+
+Certainly, if you put the old kind of pragma Inline all over the place,
+you somewhat defeat the purpose of separate compilation: you have to
+regenerate code for calls when you change the body.  But it's the
+programmer's choice to make that trade-off.
+
+My philosophy of pragma Inline is: I'm not trying to improve speed.  I
+have speed requirements.  If I have pragma Inline, I have the freedom to
+use procedural abstraction whenever I like, without worrying about
+efficiency.  Without pragma Inline, I have to perturb my design to
+achieve efficiency.
+
+I view my proposed Inline-like pragma the same way: I can freely put
+this record type in a package body, because it makes sense to do so,
+secure in the knowledge that if it's too slow, I can always "Inline"
+it.
+
+> I see the "in body" as allowing more dynamically constructed
+> systems.  Pragma inline goes just the opposite, increasing
+> the amount of statically bound decisions.
+
+Right, but the point is, you can choose the looser binding at the
+expense of efficiency, or the other way around, at the drop of a hat.
+
+>...  I also don't
+> see why this is expected to be so inefficient, given how often
+> one ends up with a dynamically-sized type already.
+
+I don't agree: I have lots of records that are compile-time-known size,
+and I want the compiler to take advantage of that.  More precisely, I
+want the compiler to *be* *able* to take advantage of that, if I so
+desire.
+
+It's true that many things are dynamic-sized.  But that does not imply
+that if we make *everything* dynamic sized there's little cost.
+
+> Perhaps the idea is that while the system is being developed, the
+> dynamic approach is great, but once you want to deliver the most
+> heavily optimized version, you can "inline" things.
+
+Yes.
+
+That's how I use pragma Inline already.
+
+One point is that when I first write the code, I might not know which
+way I want to do the trade-off.  So I want to be able to change my mind,
+without redesigning the structure of the program.  Moving something from
+body to private part is a big deal, because it rearranges the
+with_clauses, and I might have to change private packages to public
+(which ripples).  Slapping on a pragma is much easier.
+
+>...  I can't imagine
+> going to the bother of using "in body" if you "inline" right away.
+
+First: I probably don't "inline_private" (or whatever it's called) right
+away.
+
+Second: Even if I do, I still get the advantage of textually separating
+stuff out into the body.
+
+Third: I would like a compiler option to turn off pragmas Inline (the
+traditional variety, and the new one), so I can easily build my program
+both ways.
+
+****************************************************************
+
+From: Robert A Duff
 Sent: Saturday, February 17, 2001 9:53 AM
 
 Randy says:
@@ -1797,5 +1870,666 @@
 nearly identical endpoints.  I think that in Bob's ideal endpoint it would
 become obsolete.  I'm no longer sure about yours.  If not, it would never
 become a deprecated feature unless Bob converted you.  :-)
+
+****************************************************************
+
+From: Robert A Duff
+Sent: Saturday, February 24, 2001 4:11 PM
+
+I've been away for a week, and I'm beginning to catch up on e-mail...
+
+Mike Y says:
+
+> On this issue I agree with Pascal and Ehud. But let me start by quoting Bob
+> quoting Tucker:
+>
+>
+> > > I think rather than trying to make private parts more sophisticated,
+> > > we should investigate simplifying them, and pushing more stuff
+> > > to the body.
+> >
+> >This sounds like an excellent plan.  Should have happened 20 years ago.
+> >;-)
+> [discussion of how Bob's ideal language would work snipped]
+>
+> I'm skeptical we had the knowledge needed to do this right 20 years
+> ago.
+
+I should have said "I *wish* it had happened 20 years ago."
+I didn't really mean to imply that the designers of Ada 83
+were somehow negligent in not doing so.
+
+>...I'm skeptical we know *today* how to do it right.
+
+I'm quite sure that I could design a language from scratch with the
+desired property (although I could not have done so 20 years ago!).
+But I'm not so sure I know how to retrofit it into Ada, with the usual
+constraints on upward compatibility, and not breaking everybody's
+compiler.  My approach is to think about what I really want in an ideal
+world, and then think about how to fit it into the real world.
+
+>...  (Yes, it is
+> possible if code generation is always done at what we call "link
+> time.")
+
+I don't intend to require link-time code generation.
+
+****************************************************************
+
+From: Robert A Duff
+Sent: Saturday, February 24, 2001 4:40 PM
+
+I wrote:
+
+> > The implementation I'm imagining for a library-based compiler is that
+> > the compiler has a rule that if there's a private part, you have to
+> > submit it to the compiler at the same time as you submit the visible
+> > part.  Eg, if there's a command-line interface, you would type in two
+> > file names.  If you don't, and the private part turns out to exist at
+> > link time, then complain.
+
+Pascal replied:
+
+> So the model you have in mind is merely a #include, right?
+
+Pretty close.  But I still expect a separate private part to be
+separately parsed -- it's not like C, where the #include'd thing can be
+any sequence of tokens.  (Or is it even worse -- can C tokens span an
+#include?  I don't know C that well.)
+
+>...  Fine, but that's
+> outside of the language in my opinion.  I don't believe you can phrase the
+> above discussion in RM terms, i.e. "entered in the environment."
+
+I think I *can* phrase it in RM terms, as much so as current chap 10
+stuff, which is always subject to crazy "source representation"
+decisions by imaginary evil implementers.
+
+The "environment" is the universe known to the compiler.  Certainly, the
+compiler defines that universe.  But sane compilers define it sanely.
+And whatever your compiler's notion of what exists in the universe, you
+can tell (at link time) what exists in that universe.
+
+****************************************************************
+
+From: Robert A Duff
+Sent: Saturday, February 24, 2001 5:00 PM
+
+> <<We fixed one "problem" like that: optional package bodies.  However, I
+> think that was a mistake.  I think there *was* no language problem.
+> The problem was an implementation one: Ada 83 compilers ought to have
+> checked whether an optional body exists.  They didn't, and that led to
+> the error-prone behavior.>>
+>
+> I strongly disagree, ...
+
+OK, I retract my statement that there was no language problem.
+Ada 83 required (or seemed to require) error-prone behavior.
+
+However, I still say that we didn't need to fix it by
+requiring/forbidding package bodies.  I claim that optional package
+bodies would be just fine (not error prone) given the Ada 95 library
+model, and given sensible compilers.
+
+GNAT defines the "environment" (the universe of source code) to be the
+files you get when you say "ls *.ads *.adb" (in Unix).  At least that's
+the default, and you have search lists and whatnot, but anyway, there's
+a clearly defined set of source files, well understood by the user.  If
+some of those are "optional" package bodies, what's the harm?  If they
+exist, they should be part of the program, if not, not.
+
+Do you still "strongly disagree"?
+
+>... suppose you had the following:
+>
+> a spec p
+> a body p
+> where the body was not required
+>
+> Now you build a program with the spec and body, and everything works
+> fine.
+>
+> Now you edit the spec, and you recompile the spec, the body simply gets
+> left out.
+
+Yes, I now recall that this was required in Ada 83.
+
+But it's not required in Ada 95.  Ada 95 clearly allows an error message
+in this case (I mean, Ada 95, modified to allow optional package
+bodies).
+
+> What do you mean "check whether an optional body exists", you cannot
+> check if an optional body exists in the normal case, without searching
+> the universe. Yes, you can warn if one happens to be around, and you
+> can warn that one used to exist.
+
+Right.  You have to have some notion of "the universe", implementation
+defined, but defined so that programmers can easily tell what's in the
+universe.  If so, programmers will never be surprised.
+
+> <<Note that GNAT originally had the *same* error-prone behavior.  If an
+> optional body existed on disk, GNAT would silently ignore it.  GNAT
+> would only give the error message if you explicitly asked it to compile
+> the file, thus defeating the whole point of the new language rule
+> disallowing optional bodies.  My point here is not to gripe about GNAT
+> >>
+>
+> That's completely confused, yes, that's a problem, one that might exist
+> in any compiler, but it has nothing whatsoever to do with the problem
+> we are talking about, and which this language solution exists.
+
+I don't see the difference.  The body exists, it's optional, and the
+compiler ignores it.  That's a bug.  I don't care whether I'm compiling
+from scratch, or recompiling an existing program.  In fact, in GNAT, it
+doesn't matter which (which is good).
+
+> The new Ada 95 feature is NOT talking about issues in building programs
+> in the first place, it is talking about the error prone behavior where
+> you modify a spec that does not require a body, and the modification
+> does not force a recompilation of the body. It is *ENTIRELY* that
+> modification scenario, required to "work" in all Ada 83 compilers
+> that the new Ada 95 feature is addressing.
+>
+> What Bob Duff is referring wrt GNAT is that when you build a program
+> in the first place, where you have an improper body, then it is nice
+> if the automatic compilation tools make the effort to see if a body
+> is around (what on earth that means is of course very compilation
+> environment dependent). The "new" GNAT here searches everywhere on
+> the path for something that might be a body, and makes you get rid
+> of it. That's not always the right thing to do, but it is safer,
+> but this error check has nothing at all to do with the language
+> feature.
+
+It seems to me that this is *always* the right thing to do, and GNAT is
+entirely correct to complain about an optional body that exists (given
+Ada 95's rule).  GNAT defines its universe, and if that universe has junk
+in it, complaints are warranted.
+
+The earlier GNAT behavior was to define the optional body to not be part
+of the universe.  That's also RM-compliant behavior, but is obviously a
+bug.
+
+> I am a bit surprised at this confusion, because this was a well
+> known problem in Ada 83, that was completely eliminated in Ada 95,
+> in all Ada 95 compilers, and in all versions of GNAT, and was a
+> welcome change in Ada 95.
+>
+> Indeed if we have separated private parts, it is absolutely essential
+> in my view that we not repeat the mistake that Ada 83 made in this
+> area. Yes, you can defend against it to some limited extent by the
+> kind of peculiar searching around for possible peculiarities that
+> GNAT does, but that is not a desirable behavior.
+>
+> Note incidentally that the RM appears to prohibit the GNAT behavior,
+> because there are specific rules about new units obsoleting old ones.
+> What we do for the ACVC runs is to use a crackpot (i.e. ACVC only)
+> script that sees GNAT issue the message of an unwelcome body or spec,
+> and then deletes it and transparently reattempts the compilation.
+
+I do not agree that the RM prohibits the GNAT behavior.
+(Exegesis available upon request.)
+
+> In other words, the following sequence must work as far as the
+> ACVC tests are concerned.
+
+I'll bet these are legacy Ada 83 tests, and all right-thinking Ada 95
+compiler writers should have challenged them.  ;-)  Yes, I know it's
+easier to write a crackpot script.  ;-)
+
+> Introduce p.ads (spec needing body) and p.adb (body) into compilation
+> environment, and compile
+>
+> Introduce new p.ads (spec not needing body) into compilation environment
+> and compile.
+>
+> GNAT will reject the second attempt, but the ACVC test won't tolerate
+> that rejection, so we simply automatically delete the p.adb and proceed
+> (of course you would never want to do that automatically in real life,
+> which is why I call this a crackpot script).
+
+****************************************************************
+
+From: Robert A Duff
+Sent: Sunday, February 25, 2001 8:44 AM
+
+> Yes, indeed you can handle things this way in the source based model, but
+> that does NOT help you with the traditional library model implementation.
+
+But the source-based folks have said that they give warnings -- they
+could just as well give errors, except that the Ada 83 ACVC required
+otherwise.  So I claim that the only important *language* change in this
+area was to make those tests invalid.  And Ada 95 did that by allowing
+implementations complete freedom to define what's in the "universe" (ie
+the "environment).
+
+****************************************************************
+
+From: dewar@gnat.com
+Sent: Sunday, February 25, 2001 10:44 AM
+
+<<But the source-based folks have said that they give warnings -- they
+could just as well give errors, except that the Ada 83 ACVC required
+otherwise.  So I claim that the only important *language* change in this
+area was to make those tests invalid.  And Ada 95 did that by allowing
+implementations complete freedom to define what's in the "universe" (ie
+the "environment).>>
+
+My concern was with traditional library based implementations, not with
+source based implementations. I don't see how they could know.
+
+Remember that there must BE some mechanism in Ada 83 for
+replacing
+
+package spec + unneeded body
+
+by
+
+package spec without body
+
+and I do not see how one could distinguish this legitimate conversion
+from the accident in a library based environment. To require specific
+deletion of the body would be worryingly extra-lingual.
+
+In the source based model, GNAT is actually too fierce, it will NOT
+let you compile a package spec that allows no body if there is a body
+in sight, and insists that you get rid of the body first.
+
+In ACVC mode, it actually deletes the source file, which is conforming,
+but of course ludicrously hostile, so no one uses this weird ACVC
+script in real life.
+
+****************************************************************
+
+From: Robert A Duff
+Sent: Sunday, February 25, 2001 9:30 AM
+
+> Note that it is possible to implement this right now without any change
+> to the language (we investigated this possibility some time ago). All
+> you need is a pragma
+>
+> with x; pragma Private_Only (x);
+>
+> that says that the unit x can only be referenced in the private part.
+
+Well, maybe.  What are the exact semantics?  In particular, I had
+assumed that if you say "private with X;", then the scope of that
+with_clause does not include the visible part, so if there's a
+use_clause in the visible part that makes some other X visible, it is
+*not* hidden (in the vis part) by the library unit X.  This seems
+semantically nicest, and easiest to implement.  But it seems in somewhat
+bad taste for a pragma.
+
+The alternative is to say that the scope of the with_clause includes the
+visible part, but you're just not allowed to refer to X (as a separate
+legality rule).  This would mean that if you erase the pragma, the
+program still works.
+
+> Now you can allow the private part to be in a separate file, with the
+> WITH clauses in that file (and no junk pragma), and you just declare
+> that this is a representation of the text where the WITH goes where
+> it belongs with the pragma.
+
+It sounds like you're assuming the "alternative" semantics I described.
+Otherwise, it's not simply a "source representation" issue.
+
+> But it is nicer if something like this is at least semi-standardized :-)
+
+Indeed.  I wouldn't use the feature, unless I had some confidence in its
+portability.
+
+****************************************************************
+
+From: dewar@gnat.com
+Sent: Sunday, February 25, 2001 10:40 AM
+
+<<The alternative is to say that the scope of the with_clause includes the
+visible part, but you're just not allowed to refer to X (as a separate
+legality rule).  This would mean that if you erase the pragma, the
+program still works.>>
+
+Yes, that's my meaninvg of the pragma. Otherwise it is dubious indeed.
+
+<<It sounds like you're assuming the "alternative" semantics I described.
+Otherwise, it's not simply a "source representation" issue.>>
+
+Yes indeed.
+
+<<Indeed.  I wouldn't use the feature, unless I had some confidence in its
+portability.>>
+
+My definition is completely portable, since there is a reliable
+transformation from the separate files to a single file that has
+standard Ada 95 semantics, and the compiler would guarantee that
+this is the case.
+
+At least in GNAT it is pretty easy to implement, because we always
+keep track of what WITH's have actually been referenced (so that we
+give warnings if they are unreferenced), and it is just a matter of
+checking these flags at the start of the private part.
+
+****************************************************************
+
+From: Robert A Duff
+Sent: Sunday, February 25, 2001 9:38 AM
+
+> package S is  -- Note: not private, not in hierarchy T
+>   ...
+> end S;
+> -----------------------
+> package T is
+>   ...
+> end T;
+> -----------------------
+> private package T.Pr is
+>   ...
+> private
+>   ...
+> end T.Pr;
+> -----------------------
+> private with T.Pr, S;
+> pacakge T.C is
+>   -- T.Pr, S invisible here
+
+Right, but are these things in scope?  That is, can they hide other
+things of the same name?  I say, "No".
+
+Note that Tucker's idea of actually moving the with_clauses, rather than
+giving them a different syntax, better reflects the intended semantics
+(assuming folks agree with my "No").  Surely everyone agrees with the
+principle that syntax should reflect semantics!
+
+> private
+>   -- visible parts of T.Pr, S visible here
+> end T.C;
+> ------------------------------------------------------------------
+> I'm not sure about the following:
+
+Yes, the following should be allowed.  Standard is a perfectly good
+library unit, and can have public and private children like any other.
+Any other rule would be an unnecessary special case.
+
+One possible use of private children of Standard is mentioned in
+AARM-10.1.1(12.d).
+
+> private package X is  -- Note: no visible parent (except of course Standard).
+>   ...                 -- Does such a package currently,
+> private               -- i.e. without the proposed amendment,
+>   ...                 -- have any use?
+> end X;
+> -----------------------
+> private with X;  -- should this be allowed?
+> package Y is     -- Note: no hierarchical relation between X and Y
+>   -- X invisible here
+> private
+>   -- visible part of X visible here
+> end Y;
+
+****************************************************************
+
+From: Robert A Duff
+Sent: Sunday, February 25, 2001 9:20 AM
+
+> <<The explanation I've heard many times (and agree with) is that the
+> private part contains stuff that logically belongs in the body, but for
+> efficiency, we want the compiler to be able to see it (when compiling
+> clients).  In other words, it's an efficiency hack.  Calling it an
+> "interface" of some sort seems to raise it to a higher level.
+> >>
+
+Robert says:
+
+> This viewpoint seems exactly right in Ada 83, but surely is completely
+> wrong in Ada 95. The introduction of child packages that can see the
+> private part now means that indeed it is used as an interface for
+> the implementation, and I see Ada 95 code all the time where private
+> parts are full of subprogram specs that would never have fit the
+> Ada 83 model.
+
+This is a good point.
+
+However, I suspect that if private parts had never existed, then Tucker
+would have invented child units that can see the body of their parent.
+
+> So I don't think you can turn back the clock at this stage, the nature
+> of private parts of packages has radically changed from the above
+> quoted viewpoint.
+
+OK, so I guess the right viewpoint is that private parts have a two-fold
+purpose: the kludgy efficiency-hack purpose of Ada 83, and the
+interface-for-children purpose of Ada 95.  This implies that it is
+worthwhile to investigate in two directions:
+
+    1. Moving stuff into the body that is now required to be in the
+       private part.
+
+    2. Separating out the private part, either physically or logically
+       or both.  (By logically, I mean the "private with" idea, or the
+       idea of moving the with_clauses into the private part.)
+
+My earlier implication, that (1) subsumes (2), is wrong.  That is,
+achieving (1) will *not* make "private with" obsolete.  So we can make
+Pascal (etc) happy by doing (2) soon, without holding things up for (1).
+
+****************************************************************
+
+From: Robert A Duff
+Sent: Sunday, February 25, 2001 9:06 AM
+
+Tucker says:
+
+> I also don't think we should ignore the possibility of moving the
+> "with" clauses to immediately after the word "private".
+
+I am in favor of that idea.
+
+I don't buy Pascal's objection that it's useful to see this stuff up
+front.  In fact, it damages readability to see it up front, because this
+information is purely private.  One should be able to read the public
+information without being distracted.  (I support the idea of physically
+separating private parts for the same reason.)
+
+I'm only mildly worried about the "simple minded tool" issue.
+Better to improve the language than to worry about that.
+
+> I personally think we should drop discussion of physically separating
+> the "private" part, and leave that to compilers to do if they
+> so choose, especially if it is supposed to be completely
+> semantically neutral.
+
+I don't agree.
+
+Several folks have pointed out that implementations can do this anyway,
+by inventing their own syntax that claims to "represent" the standard
+Ada syntax.  That's true from a legalistic point of view.  However, from
+a practical point of view, users will want all implementations to
+support the same representation, or at least close enough that they can
+expect reasonable portability at the source file level.
+
+> But getting back to "private with" -- exactly what was the proposal?
+> I have lost it in all the other discussion.
+
+I'm not sure what exactly is the proposal, but I think it is attempting
+to solve two separate problems:
+
+1. It is currently difficult to tell whether a given with_clause is part
+of the visible information about the package.  It is desirable to mark
+each with_clause with whether it applies to the visible part, or only to
+the private part.  To me, the ideal way to indicate this would be to
+place the private with_clauses inside the private part, but some syntax
+such as "private with" also solves the problem, albeit less readably.
+
+2. It is currently illegal for a public library unit to "with" one of
+its private siblings.  Of course it only makes sense to do so if the
+private sibling is used only in the private part of the importing
+package.  Tucker seems to think this is a feature; everybody else seems
+to think it's a bug.
+
+Note that (1) was a problem even in Ada 83, when child units and private
+library units did not exist.
+
+I believe Robert has stated that problem (1) is important to solve,
+whereas (2) is merely nice to have.  And Randy and Pascal have stated
+that (2) is important, whereas (1) is merely nice to have.  (Sorry if I
+got that wrong -- I'm just trying to point out that folks disagree about
+the priorities.  I happen to think it would be nice to have a single
+stone that kills both birds.  I've been frustrated by both problems.)
+
+> Clearly we can't allow a parent package spec to "with" its own
+> private children.  So instead it must be siblings, nieces, etc.
+> that can "private with" their private siblings, aunts, etc.
+>
+> I suppose an alternative is to simply allow these "with" clauses,
+> but then say that if the with'ed unit is private, it only becomes
+> visible in the private part.  This is roughly equivalent to saying
+> that when a unit is "with"ed, if it is a private child, it
+> is implicitly inserted at the end of the private part of its parent,
+> while if it is a public child, it is implicitly inserted at the
+> end of the visible part of its parent.  In any case, a spec
+> can never "with" its own descendant.
+
+This idea solves problem (2), but not problem (1).  We can solve both
+problems at the same cost.
+
+****************************************************************
+
+From: dewar@gnat.com
+Sent: Sunday, February 25, 2001 10:47 AM
+
+<<I don't buy Pascal's objection that it's useful to see this stuff up
+front.  In fact, it damages readability to see it up front, because this
+information is purely private.  One should be able to read the public
+information without being distracted.  (I support the idea of physically
+separating private parts for the same reason.)
+>>
+
+I agree that it is quite wrong to see this up front, in fact this makes
+me realize that our headers are not quite right, we say:
+
+-- 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. --
+
+But in fact the copyright also applies to the misplaced with's :-)
+
+(legally, this is probably de minimus, still it is interesting to note
+the intersection of technical and copyright concerns here :-)
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, February 26, 2001 5:41 PM
+
+> I am in favor of that idea.
+
+I object to this idea because it turns a "simple, easy" idea into one that
+is much more complex to implement. That could easily tip the balance in
+opposition to this feature. (It does for me.)
+
+Implementing a with for which visibility appears at the private part seems
+easy: we already have things that become visible at that point, and it
+shouldn't be hard to add some additional ones. So the change is a tiny bit
+of syntax and a bit hacking.
+
+OTOH, for Janus/Ada, the "with" processing code was designed knowing that it
+only was inserting into an empty (other than other withs) symboltable. It
+wouldn't be possible to call it at the occurrence of "private" without a lot
+of reworking. (Janus/Ada is an almost pure 1-pass compiler as far as
+processing semantics is concerned.)
+
+It would be possible, of course, to (logically) transform the program into
+one where all of the context clauses are at the top -- but that would take a
+substantial new mechanism that would be quite a bit more complex than
+anything that we currently do. And, again, we would be substantially
+reworking the "with" processing (in this case, to use the transformed
+context clause rather than the one found in the syntax).
+
+We also would have to get rid of the "fast" mode from our library management
+tools, which assumes one unit per file (and thus, only reads the first few
+lines to find the context clause).
+
+I think the amount of work to implement that would outweigh any benefits (at
+least until some customer with $$$$ cares), and thus I would probably have
+to vote against it.
+
+(This really begs the question of what we're doing here. If we're adding
+small, important features to Ada 95 *now*, then making the feature more
+complex than it has to be is a mistake. If we're really designing the next
+revision of Ada, then the dynamic is quite different. The answer of what to
+do is not always the same in both cases...)
+
+****************************************************************
+
+From: Robert A Duff
+Sent: Sunday, February 25, 2001 9:49 AM
+
+> Note that the mere fact of the with's being at the top of the abstract
+> representation does not mean they have to be there in the physical
+> representation if you separate this into two separate files. There is
+> no rule that says that the only allowable way to split into two files
+> is to draw a line in the source :-)
+
+Well, Bob Duff has a personal rule that he's not willing to do fancy
+editing to convert from one so-called "source representation" to
+another.  ;-)
+
+If you give me a tool that does it automatically (or even tell me a
+simple way to write one myself), and it guarantees the same exact
+semantics, then OK.
+
+I'm arguing from a purely practical point of view here.  If we're
+serious about putting private parts in separate files, there needs to be
+a standard (concrete) syntax for doing so.
+
+****************************************************************
+
+From: dewar@gnat.com
+Sent: Sunday, February 25, 2001 10:38 AM
+
+<<Well, Bob Duff has a personal rule that he's not willing to do fancy
+editing to convert from one so-called "source representation" to
+another.  ;-)>>
+
+A reasonable rule :-)
+
+<<I'm arguing from a purely practical point of view here.  If we're
+serious about putting private parts in separate files, there needs to be
+a standard (concrete) syntax for doing so.>>
+
+I would definitely prefer that this be the case ...
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, February 27, 2001 4:31 AM
+
+> > I'm only mildly worried about the "simple minded tool" issue.
+> > Better to improve the language than to worry about that.
+>
+> We also would have to get rid of the "fast" mode from our library management
+> tools, which assumes one unit per file (and thus, only reads the first few
+> lines to find the context clause).
+
+I emphatically side with Randy here.  The "simple minded tools" are very
+important to the usability of compilation systems, and they are quite hard to
+get right.  Changing them can be a significant part of the effort involved, so
+if we want to be serious in assessing the cost and benefits of any language
+change, we have to look at the entire picture.
+
+Our environment uses a "simple minded" parser to determine the compilation order
+of units.  This parser looks at the beginning of a file for the withs and
+separate clause, and returns a skeleton Diana tree which we use to compute the
+compilation order.  With the proposed change this parser would have to become a
+full-fledged parser because nearly every language construct can appear in the
+visible part of a package (in particular, all the expression stuff would have to
+be there).  Moreover, we would lose a useful capability: with the current
+mechanism, we are able to compute the compilation ordering even if units have
+syntax errors.  If we need to parse more text, it's likely that syntax errors
+would cause us to give up and produce an incorrect ordering.
+
+And then of course, there is this "simple minded tool" named ASIS, which we used
+ubiquitously in our products.  Adding a new predicate to ask whether a with
+clause is a "private with" looks easy.  Adding a new context_clause after the
+word private would require substantial restructuring of the interfaces that
+analyze compilation units.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent