CVS difference for ai05s/ai05-0158-1.txt

Differences between 1.6 and version 1.7
Log of other versions for file ai05s/ai05-0158-1.txt

--- ai05s/ai05-0158-1.txt	2010/01/21 05:25:54	1.6
+++ ai05s/ai05-0158-1.txt	2010/06/13 05:10:50	1.7
@@ -273,8 +273,8 @@
 From: Robert Dewar
 Date: Monday, March 30, 2009  10:11 PM
 
-> If they're only for static discrete types (as in case statements, 
-> based on Tucker's responses), then I surely agree that they're easy to 
+> If they're only for static discrete types (as in case statements,
+> based on Tucker's responses), then I surely agree that they're easy to
 > implement. I'm not so sure in other cases.
 
 I gave a semantic equivalence, and no, it is not acceptable to limit these to
@@ -623,7 +623,7 @@
 From: Ed Schonberg
 Date: Sunday, November 1, 2009  10:25 AM
 
-Here is an updated version of AI05-0158 (membership tests)   
+Here is an updated version of AI05-0158 (membership tests)
 incorporating the changes suggested by you and Robert.
 The new syntax is unambiguous, and presents a minuscule incompatibility with Ada2005.
 
@@ -693,3 +693,736 @@
 I'll fix it when I post it. [And I did - ED]
 
 ****************************************************************
+
+From: Steve Baird
+Date: Tuesday, May 18, 2010  3:33 PM
+
+Ed and I are supposed to come up with improved name resolution rules for
+AI05-0158, preferably before Thursday's conference call.
+
+Just to recap, the AI currently says
+
+   If the membership_choice_list in a membership operation has more that
+   one choice, then all choices must have a single common type, which is
+   the tested type of the operation.
+
+and
+
+   The expected type of a choice_expression in a
+   membership_choice is any type.
+
+These rules would disallow
+
+    F in 10 | X
+
+, which seems undesirable.
+
+Following the wording proposed earlier for conditional expressions, we could
+replace the above with:
+
+If the membership_choice_list in a membership operation has more than one choice, then the tested type of the membership operation shall be determined by the types of the choices as follows:
+   o if all choices have the same type, then
+     that type is the tested type of the membership operation;
+   o otherwise, if at least one choice has a
+     non-universal type and every other choice has either
+     that type or a universal type which covers
+     that non-universal type, then the non-universal type is the
+     tested type of the membership operation;
+
+and
+
+    The expected type of a choice_expression in a membership_choice
+    is the tested type of the membership operation.
+
+I think this would be an improvement, but thought may be needed for dealing with
+interactions between universal_real and universal_fixed. I think the above rule
+would disallow
+
+    X : Some_Fixed_Point_Type:= ... ;
+  begin
+    if X in Duration'Last / 2.0 | 1.0 then ...
+
+and we need to decide whether a) this is a problem and b) it warrants fixing.
+Incidentally, this is less of a problem for conditional expressions because the
+context of a conditional expression can impose an expected type or a "shall
+resolve to" type, which would then allow this case.
+
+Note that the wording would be a bit more complex, but it would be conceptually
+cleaner to lump the tested expression in with the choices in determining the
+tested type of the membership operation. In the above example, we would then
+consider three expressions
+    X , Duration'Last / 2.0 , and 1.0
+instead of just the last two and the problem would (in this particular case)
+vanish.
+
+Wording note. I used the phrase "has the type" above instead of "is of the type"
+because of my (perhaps mistaken) impression that this is better when talking
+about a range. If we decide that it is perfectly ok to say that "X .. Y is of
+the type T", then the wording should be be changed to be consistent with the
+conditional expressions proposal. I understand that there is no problem with
+"the type of X .. Y is T" - I'm just not 100% sure that it therefore follows
+that it is ok to say that "X .. Y is of the type T" because that sounds (perhaps
+just to me) as if it is saying that "X .. Y is a value of type T", which is
+incorrect.
+
+P.S. There may be a font issue with the current version of the AI.
+When it says,
+
+     membership_choice ::= choice_expression | range | subtype_mark
+
+, I see "range" displayed as a reserved word rather than as a nonterminal.
+
+****************************************************************
+
+From: Gary Dismukes
+Date: Tuesday, May 18, 2010  6:22 PM
+
+> These rules would disallow
+>
+>     F in 10 | X
+>
+> , which seems undesirable.
+
+Agreed that such cases should certainly be allowed.
+
+This seems closely analogous with membership tests with ranges (F in 10 .. X), so it seems like we should be able to use similar resolution rules for these new guys.  However, after looking at the rules, I'm scratching my head about how the existing wordi
ng works for such membership tests.  The rules are based on the "type of the range", but it's unclear how that gets determined in "mixed-type" cases like the above.  (Relevant paragraphs are 4.5.2(3/2) and 3.5(4-5).)
+
+BTW, I discussed this with Steve, and it's similarly unclear to him, but maybe someone else can shed some light.
+
+> Following the wording proposed earlier for conditional expressions, we
+> could replace the above with:
+>
+> If the membership_choice_list in a membership operation has more than
+> one choice, then the tested type of the membership operation shall be
+> determined by the types of the choices as follows:
+>    o if all choices have the same type, then
+>      that type is the tested type of the membership operation;
+>    o otherwise, if at least one choice has a
+>      non-universal type and every other choice has either
+>      that type or a universal type which covers
+>      that non-universal type, then the non-universal type is the
+>      tested type of the membership operation;
+>
+> and
+>
+>     The expected type of a choice_expression in a membership_choice
+>     is the tested type of the membership operation.
+
+Maybe OK, but it would be nice to have something simpler.
+
+> I think this would be an improvement, but thought may be needed for
+> dealing with interactions between universal_real and universal_fixed.
+> I think the above rule would disallow
+>
+>     X : Some_Fixed_Point_Type:= ... ;
+>   begin
+>     if X in Duration'Last / 2.0 | 1.0 then ...
+>
+> and we need to decide whether a) this is a problem and b) it warrants
+> fixing. Incidentally, this is less of a problem for conditional
+> expressions because the context of a conditional expression can impose
+> an expected type or a "shall resolve to" type, which would then allow
+> this case.
+
+I can't get too excited about that kind of case.
+
+> Note that the wording would be a bit more complex, but it would be
+> conceptually cleaner to lump the tested expression in with the choices
+> in determining the tested type of the membership operation.
+> In the above example, we would then consider three expressions
+>     X , Duration'Last / 2.0 , and 1.0
+> instead of just the last two and the problem would (in this particular
+> case) vanish.
+
+Again, it would be nice if we could adapt the resolution rules used for range
+membership tests (assuming those aren't broken:-).
+
+****************************************************************
+
+From: Steve Baird
+Date: Tuesday, May 18, 2010  6:31 PM
+
+> Again, it would be nice if we could adapt the resolution rules used
+> for range membership tests (assuming those aren't broken:-).
+
+I agree. If we can get a better understanding of how existing range membership
+tests work (and if, as you mentioned, those rules aren't broken), then we should
+definitely take another look at the rules for the new forms of membership tests
+with that understanding in mind.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Tuesday, May 18, 2010  8:01 PM
+
+Range memberships are the only three-way resolution in Ada, where there are
+three expressions that must have the same type but there is no information from
+the context as to what types are required. (Parameters differ in this aspect,
+because the allowed types for parameters come from the possible interpretations
+of the subprogram, even for procedures.) This was a horrible mess to implement
+in our strictly top-down resolution scheme.
+
+This must be required by the ACATS, because there is no way we would have done
+that mess without some sort of requirement.
+
+How the wording implies that is required might indeed be a mystery; this could
+very well be a place where the rules of the language are determined by the ACATS
+and not the wording.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Tuesday, May 18, 2010  8:40 PM
+
+> This seems closely analogous with membership tests with ranges (F in
+> 10 .. X), so it seems like we should be able to use similar resolution
+> rules for these new guys.  However, after looking at the rules, I'm
+> scratching my head about how the existing wording works for such
+> membership tests.  The rules are based on the "type of the range", but
+> it's unclear how that gets determined in "mixed-type" cases like the
+> above.  (Relevant paragraphs are 4.5.2(3/2) and 3.5(4-5).)
+>
+> BTW, I discussed this with Steve, and it's similarly unclear to him,
+> but maybe someone else can shed some light.
+
+There is no requirement that we state how the types in name resolution get
+determined.  If you wish you try every possible type, and if you find one that
+satisfies all of the name resolution rules, then that is an acceptable
+interpretation.
+
+I agree we may be able to use similar wording as that which is used with ranges.
+Essentially we presume there is a "type of the range" and we say that the
+expected type for each bound of the range is that type.  If there are multiple
+types for which that works, then you got trouble, unless root integer or root
+real is one of them, in which case that one is preferred.
+
+One significant difference is that ranges are only for scalar types.  This new
+feature is proposed for composite types.  But I don't think that really matters.
+The resolution rules for "X" | "Y" are no worse than 'X' .. 'Y' because in both
+cases, there are multiple types in package Standard which would match both of
+these, and so they are clearly ambiguous. And we want F | "X" to work as well as
+F .. 'X', so again, making the rules similar to ranges seems like a good thing.
+
+We might have to say something about "null in new X | new Y"
+but that seems like the only one that could possibly cause a real problem.
+Perhaps we should simply disallow allocators in this construct.  There seems no
+reason to provide a preference for universal access, since no one in their right
+mind has a strong desire to write:
+
+   null in null | null
+
+We can simply declare that ambiguous (or True) and be done with it.
+
+
+>> Following the wording proposed earlier for conditional expressions,
+>> we could replace the above with:
+>>
+>> If the membership_choice_list in a membership operation has more than
+>> one choice, then the tested type of the membership operation shall be
+>> determined by the types of the choices as follows:
+>>    o if all choices have the same type, then
+>>      that type is the tested type of the membership operation;
+>>    o otherwise, if at least one choice has a
+>>      non-universal type and every other choice has either
+>>      that type or a universal type which covers
+>>      that non-universal type, then the non-universal type is the
+>>      tested type of the membership operation;
+>>
+>> and
+>>
+>>     The expected type of a choice_expression in a membership_choice
+>>     is the tested type of the membership operation.
+>
+> Maybe OK, but it would be nice to have something simpler.
+
+I think all we need to say is that last part, namely
+
+    The expected type for each choice_expression in
+    a membership_choice_list is the tested type of the
+    membership expression.
+
+We don't need to tell the implementation how to figure out the tested type, in
+the same way we don't tell them how to figure out the type of a range. We can
+simply say that a membership test has a tested type. If there is more than one
+type that satisfies the name resolution rules that govern the tested type, then
+it's ambiguous, unless one of the interpretations is a root numeric type, which
+is preferred.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Tuesday, May 18, 2010  3:33 PM
+
+...
+> I think all we need to say is that last part, namely
+>
+>     The expected type for each choice_expression in
+>     a membership_choice_list is the tested type of the
+>     membership expression.
+>
+> We don't need to tell the implementation how to figure out the tested
+> type, in the same way we don't tell them how to figure out the type of
+> a range. We can simply say that a membership test has a tested type.
+> If there is more than one type that satisfies the name resolution
+> rules that govern the tested type, then it's ambiguous, unless one of
+> the interpretations is a root numeric type, which is preferred.
+
+That would meaning requiring the ability to match an infinite number of possible
+types in any combination in cases with no context. Ada currently only requires
+three such expressions (in the X in Y .. Z case), and the expressions have to be
+scalar. That took 400+ lines of code in Janus/Ada alone; I don't see any sane
+way to generalize it. (The problem cases are things like "10 in X .. Y", where
+there is little useful type information from the "tested expression".)
+
+Even ignoring the implementation burden (which is likely to vary for other
+compilers), cases with many matching expressions is an invitation to write
+tricky code. It's possible to write expressions that resolve only because a
+single routine in a set of heavily overloaded ones is omitted. That doesn't seem
+necessary to make the goals of memberships possible.
+
+I would be against making resolution even more complicated just for this
+specific unusual case. I'd suggest making the tested expression a single type
+context, except that is neither compatible nor quite general enough (it would be
+consistent with attributes, which is the most similar other cases in the
+language). But something on that line (where the type is at least heavily
+restricted based on the tested expression) would seem to be more sensible than
+the current rules (and I'd suggest we consider extending that to all versions of
+the membership test).
+
+****************************************************************
+
+From: Tucker Taft
+Date: Tuesday, May 18, 2010  9:29 PM
+
+I wonder why this is significantly harder than:
+
+    if 10 = X + Y + Z + 3 + 77 + G + Q + R then ...
+
+These all have to be of the same integer type, and every one of these might be
+overloaded.
+
+What makes the following significantly harder?
+
+     if 10 in X | Y | Z | 3 | 77 | G | Q | R then ...
+
+I realize that "=" and "+" need to be directly visible, but does that really
+simplify the first one that much?  We can eliminate that difference with:
+
+     if A and then B and then C and then D then
+
+where A, B, C, and D all need to be of the same boolean type.  It seems like
+there are many constructs where you have more than two operands that all need to
+be of the same type.  Perhaps the key thing is to think of "|" as a binary
+operator rather than as an n-ary operator in your resolution algorithm.  Perhaps
+that would make the resolution less of a special case.
+
+Keeping the description of the resolution rules relatively simple and consistent
+with other rules in similar contexts, even if they imply a bit more work on the
+implementor's behalf, is better for the language.
+
+****************************************************************
+
+From: Edmond Schonberg
+Date: Tuesday, May 18, 2010  9:40 PM
+
+I was away from the office today, and missed this discussion.  As far as I can
+see, there are no implementation problems at all with the proposed rules, all of
+this falls out of the existing resolution machinery in GNAT. I agree with Tuck
+that the primary concern should be simplicity of description, there is nothing
+fundamentally new here concerning overload resolution.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Tuesday, May 18, 2010  10:19 PM
+
+> I wonder why this is significantly harder than:
+>
+>     if 10 = X + Y + Z + 3 + 77 + G + Q + R then ...
+>
+> These all have to be of the same integer type, and every one of these
+> might be overloaded.
+>
+> What makes the following significantly harder?
+>
+>      if 10 in X | Y | Z | 3 | 77 | G | Q | R then ...
+>
+> I realize that "=" and "+" need to be directly visible, but does that
+> really simplify the first one that much?
+
+Yes. In the first case, there is the context of "any Boolean", which is then
+used to prune the set of possible "=" operators. Then each "=" operator is used
+(in turn) to resolve the parameters. In this case, the "10" doesn't cause many
+to fail, so there are a lot of attempts on the RHS. But it is just repeating the
+same thing over and over. Moreover, in practice it doesn't ever get bad (other
+than in ACATS-type tests). We didn't believe this in the early days of our
+compiler, and added various things to avoid redoing work; but eventually I found
+that the slowness we were trying to eliminate came almost solely from the
+various techniques to avoid redoing work -- less than 1% of work ever was
+redone, and it wasn't worth any overhead to avoid that.
+
+In the second case, we have just air to start with; there is no information at
+all about what to resolve to. The only way that I can see to resolve this with
+the current technology would be a create a list of all possible types and try
+each of them in turn. That would be several orders of magnitude more than any
+operator (even "=" rarely has more than 20-30 copies visible). And I wonder
+whether that could handle anonymous types, classwide types, and the like
+properly.
+
+> We can
+> eliminate that difference with:
+>
+>      if A and then B and then C and then D then
+>
+> where A, B, C, and D all need to be of the same boolean type.
+
+I don't see anything eliminated here. "and then" is a always visible Boolean
+operator for the purposes of resolution. In fact, it is that for *all* purposes
+within Janus/Ada: it's just an operator. They're even declared in the
+symboltable (with names of "At" and "Others" so that nothing can hit them in a
+lookup). Since we chain all of the declarations with the same defining name, we
+can get the list of them trivially, and that gives us a small list of possibles
+to resolve to.
+
+>  It seems like there are many constructs where you have more than two
+> operands that all need to be of the same type.
+> Perhaps the key thing is to think of "|" as a binary operator rather
+> than as an n-ary operator in your resolution algorithm.  Perhaps that
+> would make the resolution less of a special case.
+
+The problem is not the operator, the problem is the lack of context. Even
+treating this as a operator, it would have to exist for all types in the closure
+of a program (you can use a membership on a type that you don't have visibility
+on), so the number is gigantic. If you're able to do that, you could just do
+that in the first place -- but I suspect that anonymous types and classwide
+types would cause problems.
+
+> Keeping the description of the resolution rules relatively simple and
+> consistent with other rules in similar contexts, even if they imply a
+> bit more work on the implementor's behalf, is better for the language.
+
+I agree. The most similar context (which is to say *no* context) to a membership
+is the prefix of an attribute. It's the current rules for memberships (or lack
+of rules) that is the anomoly. It's essentially the only context in Ada where
+there is no information from the context *and* there is no requirement for a
+"single type". That makes it very unusual.
+
+In any case, I don't think that the impossibility of implementing this in
+Janus/Ada is that big of a deal for the language. It's the possibility to write
+incredibly tricky expressions that really bothers me. Do we really want:
+
+   if F1 in F2 | F3 | F4 | F5 then
+
+to resolve if F1 is defined for Integer/Float/Character/String, F2 for
+Integer/Float/Duration/String, F3 for Float/Character/Duration/String, F4 for
+Integer/Float/Duration/Character, and F5 for Integer/Float/Character/Duration??
+
+I've already decided I hate this proposal because it makes it impossible to ever
+add proper set constraints to the language. (Such constraints need to be
+discrete and static in order to be able to affect the value set in sensible
+ways, there is no way to insist on such requirements after adding this syntax
+for memberships.) So maybe my opinion doesn't matter anymore.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Tuesday, May 18, 2010  10:23 PM
+
+> I was away from the office today, and missed this discussion.
+>  As far as I can see, there are no implementation problems at all with
+> the proposed rules, all of this falls out of the existing resolution
+> machinery in GNAT. I agree with Tuck that the primary concern should
+> be simplicity of description, there is nothing fundamentally new here
+> concerning overload resolution.
+
+I agree there is nothing new: membership is already broken, and you guys want to
+make it *more* broken. There are no other cases like it in Ada now, and the harm
+to understandability that the amazingly complex resolution brings is all out of
+proportion to the value of its use (which is simple subtypes and ranges made up
+of literals). These complex cases never happen in real use, so why burden both
+implementations *and* readers with the possibility??
+
+****************************************************************
+
+From: Tucker Taft
+Date: Tuesday, May 18, 2010  10:30 PM
+
+We do overload resolution bottom-up,
+so we never need to create a list of
+possible types.  That may be why this
+kind of thing doesn't add any significant complexity to our overload resolution.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Tuesday, May 18, 2010  10:37 PM
+
+> I agree there is nothing new: membership is already broken, and you
+> guys want to make it *more* broken. There are no other cases like it
+> in Ada now, and the harm to understandability that the amazingly
+> complex resolution brings is all out of proportion to the value of its
+> use (which is simple subtypes and ranges made up of literals).
+> These complex cases never happen in real use, so why burden both
+> implementations *and* readers with the possibility??
+
+Let me be more constructive. The problem here is that the rules assume that
+there is a way to determine the tested type from the part of the membership
+following the "in", when that is not actually true.
+
+Perhaps we should fix this for this new construct by adding the name of a type:
+
+            E1 in Integer when E2 | E2
+
+Then E2 and E3 have to resolve to Integer, and finally E1 has to resolve to
+Integer. We no longer have to guess the type to resolve to.
+
+It would be too much to ask to require this for existing memberships (although
+it would be a good idea).
+
+****************************************************************
+
+From: Edmond Schonberg
+Date: Wednesday, May 19, 2010  8:17 AM
+
+Wouldn't it be simpler to  just require the left operand to be a complete
+context? simple to state and implement,.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Wednesday, May 19, 2010  12:51 PM
+
+I thought about that, but if applied to memberships in general, it would prevent
+something like
+   10 in Some_Subtype
+which seems useful and has no resolution issues as the RHS provides a unique
+(sub)type.
+
+I also wonder what that would do to the new uses of memberships for
+accessibility checking (as anonymous access types always need to be converted to
+something). This latter I'd have to think about some more, by going back to that
+AI and looking at the examples.
+
+Doing it just for the new memberships would probably be fine, but slightly
+inconsistent.
+
+The existing wording for resolution of memberships implies that the RHS provides
+a type; if we could preserve that we wouldn't need to make any other
+incompatible change or add an inconsistency.
+
+****************************************************************
+
+From: Tucker Taft
+Date: Wednesday, May 19, 2010  1:30 PM
+
+That's most useful with named numbers.
+And those resolve just fine to universal integer.
+For compatibility, if we have a single membership choice, then we should stick
+with the current rules where the type comes from the RHS (at least officially).
+But if there is more than one choice, we could say the type comes from the LHS,
+and it can't be one of those things that requires context, like a string literal
+or a character literal or an allocator.
+
+That doesn't seem too nasty.
+
+****************************************************************
+
+From: Bob Duff
+Date: Wednesday, May 19, 2010  7:39 PM
+
+In ARG e-mails, we should use AI numbers AND titles in the subject line.  Please
+-- I'm too old to remember what AI-158 means.  ;-) Although I can guess from the
+discussion content...
+
+Tucker Taft wrote:
+
+> There is no requirement that we state how the types in name resolution
+> get determined. ...
+
+Right.  We (language designers) just give a set of simultaneous equations in N
+variables, and let the implementers figure out how to solve them. AARM hints (as
+we have in the case of assignment_statement) are nice.
+
+Edmond Schonberg wrote:
+
+> I was away from the office today, and missed this discussion.
+
+I was NOT out of the office, at least not any more than usual (i.e. I am ALWAYS
+out of THE office), but I deliberately ignored the discussion until now.  ;-)
+
+>...As far
+> as I can see, there are no implementation problems at all with the
+>proposed rules, all of this falls out of the existing resolution
+>machinery in GNAT. I agree with Tuck that the primary concern should
+>be simplicity of description, there is nothing fundamentally new here
+>concerning overload resolution.
+
+I agree.
+
+On the other hand, I'm not entirely opposed to Randy's view, that having type
+information flow right-to-left in the syntax tree is not really helpful in terms
+of readability.
+
+Randy Brukardt wrote:
+
+> Perhaps we should fix this for this new construct by adding the name
+> of a
+> type:
+>
+>             E1 in Integer when E2 | E2
+>
+> Then E2 and E3 have to resolve to Integer, and finally E1 has to
+> resolve to Integer. We no longer have to guess the type to resolve to.
+
+But this is just:
+
+    Integer'(E1) in E2 | E2
+
+Whatever the resolution rules, we already have syntax to nail down the type of
+E1.
+
+Randy Brukardt wrote:
+
+> In any case, I don't think that the impossibility of implementing this
+> in Janus/Ada is that big of a deal for the language.
+
+I think that's a key (political) point!
+
+Difficulties for Janus/Ada are interesting as a data point, but we should not
+outlaw new features simply because of difficulties for Janus/Ada. Sorry, Randy,
+but I think that makes sense at this point.
+
+On the other hand:
+
+>...It's the possibility to
+> write incredibly tricky expressions that really bothers me. Do we
+>really
+> want:
+>
+>    if F1 in F2 | F3 | F4 | F5 then
+>
+> to resolve if F1 is defined for Integer/Float/Character/String, F2 for
+> Integer/Float/Duration/String, F3 for Float/Character/Duration/String,
+> F4 for Integer/Float/Duration/Character, and F5 for
+> Integer/Float/Character/Duration??
+
+I'm generally in agreement with Randy's discomfort with this sort of thing,
+purely from a readability point of view (nothing to do with implementation
+difficulties).
+
+****************************************************************
+
+From: Edmond Schonberg
+Date: Wednesday, May 19, 2010  7:53 PM
+
+> I'm generally in agreement with Randy's discomfort with this sort of
+> thing, purely from a readability point of view (nothing to do with
+> implementation difficulties).
+
+One can feel plenty of discomfort with this kind of code, but
+
+a) no one writes this sort of thing (expect eager ACATS designers :-)!
+
+b) It should just fall out of a proper resolution machinery. We have known since
+1982 that the proper resolution algorithm needs two passes: one upwards to
+collect interpretations, and one downwards to resolve overloading.  I don't
+recall the authors of the paper right now, but the point is that the set of
+simultaneous equations that Bob mentions can be shown to be solved by just these
+two passes, and not require some arbitrary iteration, which is rather nice.
+
+c) without some notion of set intersection I have no idea how one can
+resolve an assignment statement   F (X) := G (X);
+
+when both sides are overloaded. There are two sets of candidate interpretations
+for F and G, and you need to find the (hopefully unique) common type between the
+two sets.
+
+Once you have that, the resolution of
+     if F1 in F2 | F3 | F4 | F5 then
+
+proceeds by performing these intersections repeatedly to find the common
+interpretation, if any.  In practice of course the alternatives will be
+constants of a some enumeration type and the heavy machinery will not be used.
+In any case, there are no implementation difficulties.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Wednesday, May 19, 2010  8:37 PM
+
+> b) It should just fall out of a proper resolution machinery.
+> We have known since 1982 that the proper resolution algorithm needs
+> two
+> passes: one upwards to collect interpretations, and one downwards to
+> resolve overloading.  I don't recall the authors of the paper right
+> now, but the point is that the set of simultaneous equations that Bob
+> mentions can be shown to be solved by just these two passes, and not
+> require some arbitrary iteration, which is rather nice.
+
+Whoa! "Proper resolution algorithm"?? What on earth are you talking about? I
+recall such a paper back in the dark ages, which was really hard to understand
+and also used way to much memory for our 56K CP/M systems. It simply wasn't
+practical.
+
+In any case, it also turns out that all of this concern about efficiency of
+resolution is misplaced. On real programs, it simply doesn't matter how it is
+done. The only problem we ever had with our recursive resolution was with an
+ACATS test that contained 50 concatenation operators, and the solution was to
+resolve the parameters in the reverse order. (You could still trigger a problem
+with an expression with 40+ levels of parentheses and heavily overloaded
+operators like "&", but I've yet to see such an expression in practice or in the
+ACATS.)
+
+> c) without some notion of set intersection I have no idea how one can
+> resolve an assignment statement   F (X) := G (X);
+>
+> when both sides are overloaded. There are two sets of candidate
+> interpretations for F and G, and you need to find the (hopefully
+> unique) common type between the two sets.
+
+You need more imagination. :-)
+
+Since the LHS of an assignment is always into a Name of some sort, we start with
+the list of solutions for that Name (such a list has to exist, and it is set up
+before we start any resolution), and then try resolving the RHS for each of the
+types determined by the solutions (usually, there is only one, of course). There
+must be exactly one that works (well, it's bit more complex than that because of
+the preference rules for root_integer/root_real).
+
+That doesn't extend well because in other cases we cannot assume the expression
+is a Name. Nor do we have any way to hold onto any "set" of results; all we are
+keeping track of is whether exactly one solution has been found and the type of
+that solution.
+
+> Once you have that, the resolution of
+>      if F1 in F2 | F3 | F4 | F5 then
+>
+> proceeds by performing these intersections repeatedly to find the
+> common interpretation, if any.  In practice of course the alternatives
+> will be constants of a some enumeration type and the heavy machinery
+> will not be used. In any case, there are no implementation
+> difficulties.
+
+As I have repeatedly said, this is not true. There is never a "set" of results
+to intersect in any place in Janus/Ada; it's all done with code and scalar local
+variables. In early versions of Janus/Ada (up until 32-bit versions, not widely
+used until the mid 90s, long after all of the basic parts of our compiler were
+designed), heap space was limited to 64K and thus was at an extreme premium,
+thus we *always* used code rather than data structures if that was possible.
+Sets of arbitrary items are expensive in that context; we only built them when
+absolutely necessary (the set of possible solutions was one such case, and it
+was a major problem in terms of memory usage and heap fragmentation).
+
+There is a later compiler phase that walks the tree to remove unused
+interpretations and enforce legality rules; it has nothing to do with
+resolution.
+
+In any case, we're clearly talking past each other. I'm not going to support
+this with general resolution, period, both because I think the potential cost in
+readability is dangerous and unnecessary, and because I cannot in good
+conscience vote for anything that is against the interests of RRS (at least
+without significant user benefit, and this resolution rule has none). Further
+discussion of this sort is futile.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent