"Eric Hughes" <eric.eh9@[EMAIL PROTECTED]
> wrote in message
news:d9065e94-8586-4889-b5c7-a8ca9e8f2248@[EMAIL PROTECTED]
> First, a historical question: Was there a proposal for user attributes
> that was considered for Ada 2005?
Not seriously. It had been rejected for Ada 95, and in general, we didn't
want to rehash that old ground.
....
> 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.
Recall that '.' in Ada always includes an implicit dereference (and the
prefixed notation also sup****ts the reverse, an implicit 'Access). That
is,
A.B(C);
could mean
B(A, C);
or
B(A.all, C);
or
B(A'access, C);
The latter should not be allowed for untagged types (they're not
implicitly
aliased). But, also it would be possible for it to mean
B(A.all.all, C);
and
B(A.all.all.all, C);
and so on forever.
That caused definitional and implementation problems. So we only allowed
tagged types.
That's OK, because only tagged types work "right" in Ada. There are a
number
of bizarre behaviors (one involves "=" of types with components, and
another
with the "reemergence" of predefined operations inside of a generic) that
had to be retained from Ada 83 for compatibility reasons. These language
mistakes are corrected with tagged types.
Thus, I think virtually all new composite types should be tagged in Ada
programs; you'll be a lot happier for it. Keep in mind that the only
runtime
overhead for a tagged object in Ada is the space for the tag and the time
to
fill it in on initialization; calls are statically bound unless you use
T'Class somewhere.
I usually go further and say all new types should be controlled (so as to
get user-defined finalization), but that does have a small runtime
overhead
if not used.
Randy.
> An attribute function must evaluate at compile-time, or perhaps more
> subtly, prior to elaboration time. Much of the requisite apparatus is
> already present with static expressions and preelaborable packages.
> The standard would require an additional definition of the ability to
> pre-elaborate a function body. While such a body might be restricted
> to returning a single static expression, that seem a bit restrictive.
>
> My overall motivation (as before) is to enable better, more flexible
> library sup****t. Library sup****t gates usability and enables cost-
> justifiable selection of Ada in a greater number of application
> domains. These kinds of features are not so critical for a single
> team writing their own software, but rather come into their own when
> writing libraries for other people to use in not-yet-anticipated ways.
>
> Eric
|
