"Eric Hughes" <eric.eh9@[EMAIL PROTECTED]
> wrote in message
news:928f737d-955f-415b-93b1-ddbd24fbf81e@[EMAIL PROTECTED]
> On Mar 13, 7:46 pm, "Randy Brukardt" <ra...@[EMAIL PROTECTED]
> wrote:
....
> > 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.
I agree. Indeed, that is a frequent gripe that we (the ARG) have, and
something we try to avoid introducing more of. But I doubt that it can
really be fixed, simply because of compatibility. We can't change the
semantics of existing programs in ways that would break much of the
existing
Ada code. We went about as far as we would ever go that way with the
deletion of return-by-reference in the Amendment. And there was a lot of
concern that we went too far (but I think that most people have agreed
that
the pain was worth the benefits).
It's the problem that occurs when you're working on something with a
substantial installed base, be it a programming language, compiler, or OS.
You don't get a blank page; you have to sup****t most of what went before.
Witness Microsoft's problems with Windows Vista as an example of what can
happen if you don't pay attention to it.
Thus you get things like tagged types which simply work better than other
kinds of types. That was introduced in Ada 95, and we have been happy to
continue it going forward.
In any case, I don't think a massive overhaul in this (or any other area)
is
very likely for Ada. Even if the result would make more sense.
Randy.
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
>
>
>
|
