Robert.Firth@BD.SEI.CMU.EDU (06/12/86)
Sorry, but I see very little problem with the
interaction between parametric procedures and
the overloading rules of Ada. Of course, the
more kinds of things you overload, the more
different types of ambiguity you get. The
important things, surely, are that these
ambiguities should not arise in unexpected
places, and that, when they do arise, they
should be resolvable.
Well, I said earlier that there were FEW cases
where parametric procedures were necessary, and
I stand by that. Therefore, you won't see many
routines defined with parametric procedures, and
those you do, like GAUSSIAN_QUADRATURE, will be
pretty unambiguous.
Now, suppose you really do get tripped up by
Anyproc("+")
There are several ways to disambiguate this.
By using named association, for instance:
Anyproc(TEXT=>"+")
Anyproc(OPERATION=>"+")
Or by dot qualification
Text_Handling.Anyproc("+")
Or by type qualification
Anyproc(STRING'("+"))
Now, you can't type-qualify the operation "+"
in TODAY's Ada, because it doesn't have a type;
it's just
function "+" (Left,Right:Integer) return Integer
But in an Ada with first-class procedures, that would
surely be written
type Binary_Integer_Operation is
function (Left,Right:Integer) return Integer;
"+" : Binary_Integer_Operation;
and you would write, therefore,
Anyproc(Binary_Integer_Operation'("+"))
On to enumerals. I concede that the fiction that an
enumeration literal is a parameterless function is just
that: a fiction. My choice would be to abandon that
fiction and hence say that you can't pass an enumeration
literal actual if the formal is a function. And in all
other cases, type-qualification can resolve any
ambiguity.
Robert Firth