On Mar 13, 7:46 pm, "Randy Brukardt" <ra...@[EMAIL PROTECTED]
> wrote:
[re: consideration of user attributes]
> Not seriously. It had been rejected for Ada 95, and in general, we
didn't
> want to rehash that old ground.
Hmm. I do admit, unless you're specifically sup****t heavy generic
programming, it's not all that useful.
I wrote:
> > And a related historical question: Why does the prefixed view of a
> > subprogram only apply to tagged types? It seems like a syntax
> > eminently suited for any subprogram.
> There are ambiguity problems because "any type" includes access types.
[...]
> That caused definitional and implementation problems. So we only allowed
> tagged types.
OK. That's a can of worms. I'm writing here, though, not to solve
that problem but to provide motivation about why a solution is
im****tant.
> That's OK, because only tagged types work "right" in Ada. [...]
>
> Thus, I think virtually all new composite types should be tagged in Ada
> programs [...]
I'm with you on the general idea. In my own code, most of my types
are tagged. But the requirement to have them tagged in order to use
the "." operator forces a trade-off: either (a) restrict generic
parameters to tagged types or (b) avoid "." notation and be required
to pull in whole packages rather than only single types. This doesn't
match up with the separation of concerns (a.k.a. orthogonality) which
is one of the hallmarks of Ada and one of the things I appreciate most
about the language. The power of generic programming is to
reinterpret the notation within a generic body through the parametric
meaning of that notation. Today, for method invocations, that means
"call through the virtual function table". That's certainly right for
tagged types. It's too restrictive for other types.
My goal is to envision a reasonable way of introducing into visibility
all the affordances of a type with just the type name and not its
whole package of definition. A hypothetical attribute such as
T'Package isn't the right thing, since it would expand visibility
(even if it were feasible to implement).
What about tagging the function rather than the type? Imaginary
example:
function Op( X : T ) return X is tagged ;
The sole purpose of the tag in this example is to mark a particular
function signature as available through "." notation.
Eric
|
