CVS difference for ais/ai-50217.txt

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

--- ais/ai-50217.txt	2003/07/26 03:26:03	1.4
+++ ais/ai-50217.txt	2003/08/01 01:40:09	1.5
@@ -3441,7 +3441,7 @@
 -----------------
 Thoughts on the implementation of "limited with" in AdaMagic
 
-          $Revision: 1.4 $ $Date: 2003/07/26 03:26:03 $
+          $Revision: 1.5 $ $Date: 2003/08/01 01:40:09 $
 
 The "limited with" clause makes a "limited view"
 of a package visible in the compilation unit
@@ -5250,7 +5250,7 @@
 -----------------
 Thoughts on the implementation of "limited with" in AdaMagic
 
-          $Revision: 1.4 $ $Date: 2003/07/26 03:26:03 $
+          $Revision: 1.5 $ $Date: 2003/08/01 01:40:09 $
 
 The "limited with" clause makes a "limited view"
 of a package visible in the compilation unit
@@ -5454,6 +5454,307 @@
 The first bullet would be replaced by "where the full type declaration
 for D is visible" for the limited-with proposal (and for the
 "type C.T;" proposal).
+
+**************************************************************
+
+From: Pascal Leroy
+Sent: Thursday, March  6, 2003  4:56 AM
+
+(I am discussing the issue below in the context of limited with, but I believe
+that the other incarnations of 217 all have similar problems if they use
+visibility to determine when the completion can be used.)
+
+A while back, in a message about implementation of limited withs in AdaMagic,
+Tuck wrote:
+
+> As mentioned above, a limited view of a package can be hidden from
+> all visibility.  The anticipated rule is that the limited
+> view is hidden from all visibility if the full view is visible
+> either "normally" or via a rename.  This implies that if
+> P.Q.R is visible, including via a rename, then P.Q.R'Limited
+> is not visible.  Furthermore, even when P.Q.R'Limited
+> is visible, it is possible that P.Q.R'Limited.NP might
+> not be visible, because P.Q.R.NP might be visible via
+> a renaming.
+
+From a user's perspective, the notion that you have a limited view of P.Q.R but
+a full view of its nested package P.Q.R.NP sounds very confusing to me.
+Especially considering that the reason why you have a full view of NP is that
+someone somewhere declares a renaming of NP.
+
+From an implementer's perspective, my head aches when I try to see how we could
+implement this.  In fact, the above description seems distinctly at odds with
+what was discussed during the meeting.  The minutes say:
+
+"Randy says that two views of the same package make the implementation much
+harder. Our implementation only expects a single view with a few well-defined
+places of visibility change. This is scattered all about. Pascal expresses
+agreement with Randy's assessment."
+
+And then the minutes present rules intended to avoid the "two views" issue
+(although arguably the problem discussed by Tucker was not addressed, at least
+as far as I remember).
+
+The implementation difficulties for us are worse than I originally thought
+because of incremental compilation.  Say that you compile a unit containing the
+name P.Q.R.NP.Var, and that name is legal because of the existence of some
+renaming of NP. Then that renaming is removed.  During incremental recompilation
+the name P.Q.R.NP.Var must be obsolesced, even though it doesn't reference the
+renaming that is being removed.  That's hard.  Not as hard as a full-fledged
+ripple effect maybe, but still hard.
+
+I understand that there is some similarity with name clashes introduced by use
+clauses, but I'd rather not add more complexity to code that is already very
+hairy.  Also note that from a user's perspective name clashes are probably quite
+rare, but visibility changes due to the introduction/removal of renamings might
+be much more frequent, and would certainly result in much puzzlement.
+
+This leads me to two questions:
+
+1 - Why did we decide to go for visibility anyway?  What would be wrong with
+using the "availability" defined in 217-05?
+2 - If we have to stick to visibility, couldn't we define the rules in such a
+way that there is only one view visible?  I'd say that the situation described
+by Tucker above should be illegal, and that if (1) you have a limited with of
+P.Q.R and (2) some renaming gives you a full view of P.Q.R.NP then your code is
+illegal.  You need to add a "with P.Q.R" to hide the limited view of P.Q.R from
+all visibility.
+
+Comments?
+
+**************************************************************
+
+From: Tucker Taft
+Sent: Thursday, March  6, 2003  8:17 AM
+
+Pascal Leroy wrote:
+...
+> From a user's perspective, the notion that you have a limited view of P.Q.R but
+> a full view of its nested package P.Q.R.NP sounds very confusing to me.
+> Especially considering that the reason why you have a full view of NP is that
+> someone somewhere declares a renaming of NP.
+
+It's not quite that bad.  Remember that you don't have
+a full view of NP using the name "P.Q.R.NP".  You have
+to use the name introduced via the renaming.  What
+you *lose* is the ability to refer to the limited view
+of NP via the name "P.Q.R.NP."
+
+...
+> The implementation difficulties for us are worse than I originally thought
+> because of incremental compilation.  Say that you compile a unit containing the
+> name P.Q.R.NP.Var, and that name is legal because of the existence of some
+> renaming of NP.
+
+This is not what I intended to propose.  Var would never be visible
+via the name "P.Q.R.NP.Var" if you have a limited view of
+P.Q.R, since objects are not included in the limited view.
+The presence of a renaming only *removes* something from
+the limited view, it never adds something.
+
+> ... Then that renaming is removed.  During incremental recompilation
+> the name P.Q.R.NP.Var must be obsolesced, even though it doesn't reference the
+> renaming that is being removed.  That's hard.  Not as hard as a full-fledged
+> ripple effect maybe, but still hard.
+
+Can you consider this again with hopefully a clearer explanation
+of what was intended?
+
+
+...
+> This leads me to two questions:
+>
+> 1 - Why did we decide to go for visibility anyway?  What would be wrong with
+> using the "availability" defined in 217-05?
+
+I think if you study the availability rules, you will find
+they are essentially the same as the proposed visibility
+rules, but just couched in different terms.  If you find
+a significant difference, I would like to know what it is.
+
+> 2 - If we have to stick to visibility, couldn't we define the rules in such a
+> way that there is only one view visible?  I'd say that the situation described
+> by Tucker above should be illegal, and that if (1) you have a limited with of
+> P.Q.R and (2) some renaming gives you a full view of P.Q.R.NP then your code is
+> illegal.  You need to add a "with P.Q.R" to hide the limited view of P.Q.R from
+> all visibility.
+
+I'm not sure what you mean here, since we started off with
+different interpretations of the proposed rule.  Could you
+restate this, and contrast it with what I have explained
+above to be the intent, namely that a rename causes things
+to be removed from a limited view, rather than being added.
+
+**************************************************************
+
+From: Pascal Leroy
+Sent: Friday, March  7, 2003  10:27 AM
+
+> This is not what I intended to propose.  Var would never be visible
+> via the name "P.Q.R.NP.Var" if you have a limited view of
+> P.Q.R, since objects are not included in the limited view.
+> The presence of a renaming only *removes* something from
+> the limited view, it never adds something.
+
+Ok, I was confused, but I still have essentially the same problems.  For
+clarity, let's look at some piece of code:
+
+    package P.Q.R is
+        package NP is
+            type T is new Boolean;
+        end NP;
+    end P.Q.R;
+
+    with P.Q.R;
+    package A is
+        package Ren renames P.Q.R.NP;
+    end A;
+
+    limited with P.Q.R;
+    -- with A;
+    procedure Main is
+        type Acc is access P.Q.R.NP.T;
+    begin
+        null;
+    end Main;
+
+If I understand you correctly, this code is legal.  However, if the "with A" in
+Main is uncommented, the declaration of type Acc becomes illegal, because
+P.Q.R.NP is hidden from all visibility.
+
+From a user's perspective, I still find this rule mysterious, but maybe it's not
+going to happen frequently in practice.
+
+From an implementer's perspective I still have to have two views around:
+P.Q.R'Limited for all of P.Q.R except P.Q.R.NP, and P.Q.R'Full for P.Q.R.NP (but
+only when it is accessed through the renaming).  It means that there are a
+zillion places in my compiler where I need to ask the question: which view do I
+see?  This is feasible, but I'm sure I won't get it right the first time (or the
+second time).
+
+Now looking at incremental compilation again, you have not solved my problem.
+Say that we had the "with A" all along, but initially A didn't include the
+renaming.  Then someone adds that bloody renaming.  The name P.Q.R.NP.T in Main
+must be obsolesced, even though it doesn't reference A.  Let me say it once
+more: that's hard.
+
+> I think if you study the availability rules, you will find
+> they are essentially the same as the proposed visibility
+> rules, but just couched in different terms.  If you find
+> a significant difference, I would like to know what it is.
+
+It's hard to tell for sure because the availability rules in 217-05 are
+formulated in terms of type stubs.  But if you try to adapt them for "limited
+withs", it would seem that you'd have to say that the completion of T is
+available (1) within the extended scope of the completion of T and (2) within
+the scope of a (nonlimited) with clause for the package that declares T. I fail
+to see how this would cause a "with A" to hide P.Q.R.NP from all visibility. In
+fact I fail to see how the presence of "with A" would have any bearing on the
+visibility of entities exported by P.Q.R.
+
+It seems to me that if we used availability, the completion of T would not be
+available in Main (regardless of whether there is a "with A" or not) and
+therefore we would have only one view of P.Q.R, the limited one.
+
+> I'm not sure what you mean here, since we started off with
+> different interpretations of the proposed rule.  Could you
+> restate this...
+
+Forget it, the scheme that I had in mind would introduce ripple effects.
+
+**************************************************************
+
+From: Tucker Taft
+Sent: Friday, March  7, 2003  12:12 PM
+
+> If I understand you correctly, this code is legal.  However, if the "with A"
+> in Main is uncommented, the declaration of type Acc becomes illegal, because
+> P.Q.R.NP is hidden from all visibility.
+
+Right.
+
+> From a user's perspective, I still find this rule mysterious, but maybe it's
+> not going to happen frequently in practice.
+
+It shouldn't, because it only happens if a piece of code
+has a limited-with on something on which it depends
+semantically.
+
+...
+> It's hard to tell for sure because the availability rules in 217-05 are
+> formulated in terms of type stubs.  But if you try to adapt them for "limited
+> withs", it would seem that you'd have to say that the completion of T is
+> available (1) within the extended scope of the completion of T
+
+Unless we change the definition of scope, this would include all semantic
+dependents of the package where the completion is declared (see 8.2(10)).
+So this would create ripple effects and would be even worse,
+as far as incremental recompilation, I presume.
+
+I really think you need to address 8.3(19) which says within the
+*scope* of the completion, the first declaration is hidden from
+all visibility.  I have proposed changing this to say where the completion
+is visible (including via a renaming), the first declaration is hidden
+from all visibility.  We can fiddle with these words further,
+since they really only affect this new case.
+
+> ... and (2) within
+> the scope of a (nonlimited) with clause for the package that declares T.  I fail
+> to see how this would cause a "with A" to hide P.Q.R.NP from all visibility.  In
+> fact I fail to see how the presence of "with A" would have any bearing on the
+> visibility of entities exported by P.Q.R.
+>
+> It seems to me that if we used availability, the completion of T would not be
+> available in Main (regardless of whether there is a "with A" or not) and
+> therefore we would have only one view of P.Q.R, the limited one.
+
+I think you are perhaps muddying things by talking about "availability"
+since that is a term that was introduced in an AI and never fully
+explored.
+
+Let's focus on this renaming thing.  I was trying to address
+the concern that you didn't want to have two views of the same package
+at the same place.  I presumed that referred to sub-packages as well.
+If a renaming does not remove NP from the limited view of P.Q.R, then
+you can see the limited view of P.Q.R.NP through that name,
+and the full view of the same package via the renaming.  I can live
+with that, but I thought we were trying to avoid that.
+
+Let's decide that question, and then construct rules that accomplish
+what we want.  We can call them "visibility" or "availability" or
+"supercalifragility" rules or whatever once we decide what the rules
+should be.
+
+**************************************************************
+
+From: Pascal Leroy
+Sent: Friday, March  7, 2003  2:58 PM
+
+> Let's focus on this renaming thing.  I was trying to address
+> the concern that you didn't want to have two views of the same package
+> at the same place.  I presumed that referred to sub-packages as well.
+> If a renaming does not remove NP from the limited view of P.Q.R, then
+> you can see the limited view of P.Q.R.NP through that name,
+> and the full view of the same package via the renaming.  I can live
+> with that, but I thought we were trying to avoid that.
+
+I actually had a much more stringent requirement in mind: ideally, in the
+course of compiling a compilation unit, there would be only one view of each
+and every (compilation) unit in its closure.  If we manage to achieve this,
+it would simplify the implementation considerably.  So for instance when
+compiling Main in my example, you would either need to open P.Q.R'Full or
+P.Q.R'Limited, but not both.  And you would probably know that early in the
+compilation process, e.g. after processing the context clauses.
+
+Regarding the incremental compilation issue, the legality of a name should
+not be affected by adding/removing random declarations to random units (in
+particular, package renamings).
+
+Unsure how/if we can come up with rules that satisfy these requirements.
+
+>We can call them "visibility" or "availability" or "supercalifragility"...
+
+:-) :-)
 
 **************************************************************
 

Questions? Ask the ACAA Technical Agent