Re: User-defined type attributes

[Eric Hughes <eric.eh9@gmail.com>]

On Mar 14, 9:20 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> 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.

Well, I don't think any of the ideas I've had recently about dot-
notation are in the realm of changing pre-existing semantics.
Instead, I'm concerned with keeping existing syntax patterns,
enlarging the domain of applicability of that syntax, and creating new
semantics that match existing practice.  While that becomes more
difficult as time goes forward, I think Ada's been pretty good about
making conservative choices that attenuate the consequences of
otherwise-rash decisions.

> 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.

Tagged types do work better, sure.  But they're not a panacea,
either.  It would a mistake to address other difficulties with types
by shoehorning "solutions" to them into tags.  And in the last couple
of days I've realized the problems with untagged types as formal
parameters is much greater than the absence of dot-notation.

So here's a brief example.  I'm writing a smart accessor package set
right now.  As something of an exercise, I'm doing this as generically
as possible.  So I'm looking to write code that can use both intrusive
(part of the managed object) and accretive (separate from the managed
object) allocation strategies for reference counts.  And I want to do
it without making the accessor types tagged.  Since an intrusive
accessor is simple a wrapped-up access object, adding a tag would
double the machine size of an object.  I consider this a poor result
for a system-level library.

My first foray at solving this was to use a formal type parameter for
the implementation of the accessor.  The intrusive implementation
would contain just an access object; the accretive one would have that
plus an access to a reference count.  Pretty simple, so I thought.
But without using a tagged type in the formal parameter definition,
there's no visibility either for record components or for implicit
visibility of operators on that type.  Thus I couldn't get at
components either directly or indirectly.  I discarded that approach.

It's a shame really, because it would otherwise be a natural
representation of variety of in possible implementations.  I'm still
looking at other ways of approaching the problem.  I'm beginning to
suspect that doing this may be impossible, but I don't have an
argument yet.

Eric