limited/non-limited in Ada95

limited/non-limited in Ada95

[Tom Moran]

In Ada 83 there was always an argument against using 'limited' because
it would make anything anything using that type also limited.  But in
Ada 95 with tagged types we have the same problem in reverse: if a
tagged type is non-limited then all its descendants are non-limited and
some important capabilities are only available to limited types.  Has
anyone else found this to be a problem, and do you have any good
solutions?

Re: limited/non-limited in Ada95

[Matthew Heaney]

In article <3442C2A3.3781@bix.com>, TMoran@bix.com wrote:

>In Ada 83 there was always an argument against using 'limited' because
>it would make anything anything using that type also limited.  But in
>Ada 95 with tagged types we have the same problem in reverse: if a
>tagged type is non-limited then all its descendants are non-limited and
>some important capabilities are only available to limited types.

What "important capabilities" do limited types have?  That they're passed
by reference?  You get that for free anyway for tagged types, even if the
tagged type is non-limited.

>Has
>anyone else found this to be a problem, and do you have any good
>solutions?

Sometimes it's a pain if you have a non-limited tagged type and you want to
extend it to add an access discriminant.  But no big deal: you can use a
named access type as the discriminant and O'Unchecked_Access to give it a
value.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: limited/non-limited in Ada95

[Jon S Anthony]

mheaney@ni.net (Matthew Heaney) writes:

> What "important capabilities" do limited types have?  That they're passed
> by reference?  You get that for free anyway for tagged types, even if the
> tagged type is non-limited.

Well, they are _not_ necessarily passed by reference.  That is part of
what Henry Baker is (correctly) whinging about.

The most important part is that they can't be implicitly aliased -
especially via assignment.

/Jon

-- 
Jon Anthony
Synquiry Technologies, Ltd., Belmont, MA 02178, 617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: limited/non-limited in Ada95

[Matthew Heaney]

In article <ufhgaghueo.fsf@synquiry.com>, Jon S Anthony <jsa@synquiry.com>
wrote:

>mheaney@ni.net (Matthew Heaney) writes:
>
>> What "important capabilities" do limited types have?  That they're passed
>> by reference?  You get that for free anyway for tagged types, even if the
>> tagged type is non-limited.
>
>Well, they are _not_ necessarily passed by reference.  That is part of
>what Henry Baker is (correctly) whinging about.
>
>The most important part is that they can't be implicitly aliased -
>especially via assignment.

I don't understand Henry's problem.  If I implement a bank account as

package Bank_Accounts is

   type Bank_Account is limited private;
...
private

   type Bank_Account is
      limited record
         Money : Dollars := 0.0;
      end record;

end;

Then what's the problem?  Always implement the full view as a limited
record.  (My only complaint is that you can't apply the limited qualifier
to other types, not even arrays.  Bummer.  So you have to wrap the type in
a limited record.  Oh well.)

I agree that aliasing can comprimise the safely of a limited type (everyone
ought to read Baker's Limited Robbery paper), but if the programmer always
implements a limited private type by using a full view that is itself
limited - which one can do in Ada 95 - then there is no problem.

<ftp://ftp.netcom.com/pub/hb/hbaker/LimitedRobbery.ps.Z>
<ftp://ftp.netcom.com/pub/hb/hbaker/LimitedRobbery.html>

If the programmer doesn't use a by-reference type, then it's a case of
programmer indolence, not a language problem.

All the same, it would be really swell if compilers would tell you when you
implement a limited private type using a type that isn't passed by
reference.  It would be cool too if that were added as an argument to
pragma Restrictions, something like
Full_View_Of_Limited_Private_Must_Be_Limited.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: limited/non-limited in Ada95

[Tom Moran]

>important capabilities of limited types
The one that bit me most recently was that you can't have access
values as discriminants of non-limited types.

Re: limited/non-limited in Ada95

[Matthew Heaney]

In article <3449390f.142507@SantaClara01.news.InterNex.Net>, tmoran@bix.com
(Tom Moran) wrote:

>>important capabilities of limited types
>The one that bit me most recently was that you can't have access
>values as discriminants of non-limited types.

Yeah, a pain, but will this work?

type DT is ...;
type DT_Access is access all DT;

type T (D : DT_Access) is private;

You can then use Unchecked_Access:

declare
   D : aliased DT;
   O : T (D'Unchecked_Access);
begin

Will that do what you want?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: limited/non-limited in Ada95

[Tom Moran]

>type DT is ...;
>type DT_Access is access all DT;

>type T (D : DT_Access) is private;

>You can then use Unchecked_Access:

>declare
>   D : aliased DT;
>   O : T (D'Unchecked_Access);
>begin
Could you expand on that, I'm confused.  I'd like 
   -- existing type T is limited, tagged
  type Newer(X:in some_access_type) is new T with ...

Another problem is that once a tagged type is non-limited, no
extension can be, or have components that are,llimited.

Re: limited/non-limited in Ada95

[Matthew Heaney]

In article <344a4329.812635@SantaClara01.news.InterNex.Net>, tmoran@bix.com
(Tom Moran) wrote:

>>type DT is ...;
>>type DT_Access is access all DT;
>
>>type T (D : DT_Access) is private;
>
>>You can then use Unchecked_Access:
>
>>declare
>>   D : aliased DT;
>>   O : T (D'Unchecked_Access);
>>begin
>Could you expand on that, I'm confused.  I'd like 
>   -- existing type T is limited, tagged
>  type Newer(X:in some_access_type) is new T with ...

I thought the problem was that, because T was non-limited, you couldn't add
an access discriminant.  But you can add a discriminant of a named access
type as a discriminant, even if the type is non-limited.  (Note: "access
discriminant" and "discriminant of a named access type" are two different
things.  The former is only allowed for types that are limited.)

If T is limited, then it's probably simpler just to add an access
discrimant to the derived type:

type T is tagged limited private;

type NT (D : access DT) is new T with private;

Although it's perfectly legal to make the discriminant of NT have a named type:

type NT (D : DT_Access) is new T with private;


>Another problem is that once a tagged type is non-limited, no
>extension can be, or have components that are,llimited.

Yes, that's true.  But you could always add a discriminant of a named
access type to the derived type, to point to objects that are limited.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: limited/non-limited in Ada95

[Tom Moran]

>>Another problem is that once a tagged type is non-limited, no
>>extension can be, or have components that are,llimited.

>Yes, that's true.  But you could always add a discriminant of a named
>access type to the derived type, to point to objects that are limited.
  Using a (named)access type instead of the limited object directly is
ugly, increases code size and complexity, is error prone, and
expensive (eg on Windows CE where they tell you to avoid memory
allocation/deallocation as much as possible) .  Other than that, it's
just fine. :(

Re: limited/non-limited in Ada95

[Jon S Anthony]

In article <dewar.877425501@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> The view for the implementation most certainly can have limited semantics.

Anything is _possible_.  It's just not reasonable in this case.  Of
course I looked at this sort of approach.  It sucks even more than
forcing reference semantics.


> the full view is limited is not a problem. But this way you can preserve
> the abstraction. I see no problem in writing a GC implementation using
> this approach, and in fact we worked out exactly how to do this in the
> context of the GNAT project, though no one ever followed through with

I'm not talking about situations where you can have privleged
knowledge and support by/from the compiler.  Sure, in that sort of
case the entire issue is irrelevant (but proprietary and tied to a
single implementation).

/Jon
-- 
Jon Anthony
Synquiry Technologies, Ltd., Belmont, MA 02178, 617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: limited/non-limited in Ada95

[Robert A Duff]

In article <JSA.97Oct20202120@alexandria.synquiry.com>,
Jon S Anthony <jsa@alexandria.synquiry.com> wrote:
>In article <mheaney-ya023680001810971145040001@news.ni.net> mheaney@ni.net (Matthew Heaney) writes:
>> I agree that aliasing can comprimise the safely of a limited type (everyone
>> ought to read Baker's Limited Robbery paper), but if the programmer always
>> implements a limited private type by using a full view that is itself
>> limited - which one can do in Ada 95 - then there is no problem.
>
>There are important cases where this is at _best_ impractical and
>actually is more like not _feasible_.  The _view_ for the
>implementation should not (can _not_) have limited semantics.  This is
>particularly evident when you are constructing GC for Ada _within_ the
>language.  Since this is one of Henry's main baileywicks, and since
>I've constructed such a GC asset suite _within_ the language, I can
>very easily understand where he is coming from.  It's _painfully_
>obvious when you have to actually deal with the situation.

Well, the rest of the world hasn't seen your GC stuff.  At least I
haven't.  So I can't quite understand what you're getting at, here.
What's wrong with having:

    type T is limited private;

then:

    type T_Contents is ...; -- not limited!
    type T is
        limited record -- to keep Henry from stealing bank accounts ;-)
            Contents: T_Contents;
        end record;

Now clients see a by-reference (return-by-reference, even!) type T, but
the implementation of the package itself can do assignments via
X.Contents := Y.Contents.

?

>> If the programmer doesn't use a by-reference type, then it's a case of
>> programmer indolence, not a language problem.
>
>Rubbish.

Perhaps others more intelligent than I can understand what you're saying
here, but for me, a mere "Rubbish" isn't quite detailed enough for me to
understand your point.  Perhaps you would care to elaborate?  Maybe give
an example from your GC stuff?  I'd like to see an example illustrating
the problem, and perhaps even a suggestion as to how the rules of the
language ought to be changed.

Yes, I understand Henry's paper, but that was before "limited record"
existed.  (I read Henry's paper before Ada 9X existed, so if there's a
new version that talks about Ada 95, please tell me to go read it.)

- Bob

Re: limited/non-limited in Ada95

[Robert A Duff]

In article <mheaney-ya023680001610972221540001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>What "important capabilities" do limited types have? ...

The important capability of limited types is that you can't do
assignment.  Maybe you don't call that a "capability", but I think it
is.  Perhaps the right way to put it is: the programmer (of some
abstraction) has the capability to document the fact that no assignments
will happen on this type.  And one can trust that documentation, since
the compiler verifies it (as opposed to comments).

It's like asking, "What capability do constants have?"  After all,
variables are just like constants, but can do more things (like have
their value change).  So what's the point of constants?  Mainly, the
point is that the reader of the code knows "this thing won't change".
(There's also an efficiency point -- the compiler can take advantage of
the fact that so-and-so won't change.)

One could view "constant" as a restriction (you can't say "X := 3;") but
I think it's just the opposite -- the Ada 'constant' feature allows the
programmer to express something useful.  There's no restriction -- if
you want to change it, just say so (ie just don't make it a constant).

Likewise, for limitedness.  The fact that you can't assign to a limited
thing is not a restriction, but, on the contrary, allows the programmer
to express an interesting fact.  If you *want* to assign to it, fine,
don't make it limited.

- Bob

Re: limited/non-limited in Ada95

[Jon S Anthony]

In article <mheaney-ya023680001810971145040001@news.ni.net> mheaney@ni.net (Matthew Heaney) writes:

> I don't understand Henry's problem.  If I implement a bank account as

The problem he points out in the paper is quite clear IMO.


> I agree that aliasing can comprimise the safely of a limited type (everyone
> ought to read Baker's Limited Robbery paper), but if the programmer always
> implements a limited private type by using a full view that is itself
> limited - which one can do in Ada 95 - then there is no problem.

There are important cases where this is at _best_ impractical and
actually is more like not _feasible_.  The _view_ for the
implementation should not (can _not_) have limited semantics.  This is
particularly evident when you are constructing GC for Ada _within_ the
language.  Since this is one of Henry's main baileywicks, and since
I've constructed such a GC asset suite _within_ the language, I can
very easily understand where he is coming from.  It's _painfully_
obvious when you have to actually deal with the situation.

> If the programmer doesn't use a by-reference type, then it's a case of
> programmer indolence, not a language problem.

Rubbish.

/Jon
-- 
Jon Anthony
Synquiry Technologies, Ltd., Belmont, MA 02178, 617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: limited/non-limited in Ada95

[Robert Dewar]

Jon says

<<There are important cases where this is at _best_ impractical and
actually is more like not _feasible_.  The _view_ for the
implementation should not (can _not_) have limited semantics.  This is
particularly evident when you are constructing GC for Ada _within_ the
language.  Since this is one of Henry's main baileywicks, and since
I've constructed such a GC asset suite _within_ the language, I can
very easily understand where he is coming from.  It's _painfully_
obvious when you have to actually deal with the situation.>>


The view for the implementation most certainly can have limited semantics.
When you are writing garbage collectors, you certainly expect to do some
pretty low level fiddling at the implementation level, where the fact that
the full view is limited is not a problem. But this way you can preserve
the abstraction. I see no problem in writing a GC implementation using
this approach, and in fact we worked out exactly how to do this in the
context of the GNAT project, though no one ever followed through with
an actual implementation, since there has been no demand for GC in GNAT
so far (demand = serious customer willing to pay $)

Robert Dewar
Ada Core Technologies

Re: limited/non-limited in Ada95

[Robert A Duff]

In article <mheaney-ya023680001810971645020001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>declare
>   D : aliased DT;
>   O : T (D'Unchecked_Access);
>begin
>
>Will that do what you want?

The problem is that as soon as you use 'Unchecked_Access, you lose the
nice properties of access discriminants for preventing dangling
references.  Given the above, somebody might assign "Global := O;",
creating a dangling ref, whereas that won't happen if it were an access
discrim.

- Bob

Re: limited/non-limited in Ada95

[Matthew Heaney]

In article <344ccece.1720086@SantaClara01.news.InterNex.Net>,
tmoran@bix.com (Tom Moran) wrote:

>>>Another problem is that once a tagged type is non-limited, no
>>>extension can be, or have components that are,llimited.
>
>>Yes, that's true.  But you could always add a discriminant of a named
>>access type to the derived type, to point to objects that are limited.
>  Using a (named)access type instead of the limited object directly is
>ugly, increases code size and complexity, is error prone, and
>expensive (eg on Windows CE where they tell you to avoid memory
>allocation/deallocation as much as possible) .  Other than that, it's
>just fine. :(

No memory allocation is implied by this advice; in fact, just the opposite.

type DT is access all LT;

type NLT (D : DT) is tagged private;

...
declare
   LO : aliased LT;
   NLO : NLT (LO'Unchecked_Access);
begin

So where is the "ugliness, increase in code size, and memory allocation"? 
No use of heap is necessary.

True, this isn't as safe as an access discriminant, but if you're doing
what you'd do with an access discriminant (ie location of the variable
you're pointing to), then I don't think there's any great issue.  
Here's what one would do if you were to use an access discriminant:

type LT (D : access T) is tagged limited private;

declare
   O : aliased T;
   LO : LT (O'Access);
begin

Not much different, so I'm not clear what the objection is.  The
introduction of an "unnecessary" access type?   It is true, however, that
frequent conversions of access types will be required, when named access
types are used instead of access parameters, which is an admitted pain.

Mind you, there definately is one area where named access types must be
used "unnecessarily," and that's when you want to use an access
discriminant to designate a constant object (ie an in parameter of a
subprogram).  But the lack of "access constant" access parameters and
discriminants is a known omission in the language, and will undoubtly be
included in the next revision.  For now, we have to live with using named
access constant types (instead of the preferred access constant parameters
and access constant discriminants) and Unchecked_Access.  (Though the need
for Unchecked_Access even with access discriminants is sometimes required.)

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: limited/non-limited in Ada95

[Robert Dewar]

<<Anything is _possible_.  It's just not reasonable in this case.  Of
  course I looked at this sort of approach.  It sucks even more than
  forcing reference semantics.>>

  Saying something "sucks" without examples and a technical argument is
  not debate, it is empty rhetoric.

<<I'm not talking about situations where you can have privleged
knowledge and support by/from the compiler.  Sure, in that sort of
case the entire issue is irrelevant (but proprietary and tied to a
single implementation).>>

  I am not talking about that case either, whatever made you think I was?
  The fact that I said "in the context of the GNAT project"? By that I
  just meant that this was the context of the discussions on how to do
  things, not that we were talking about special compiler support.

Re: limited/non-limited in Ada95

[Jon S Anthony]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> 
> <<Anything is _possible_.  It's just not reasonable in this case.  Of
>   course I looked at this sort of approach.  It sucks even more than
>   forcing reference semantics.>>
> 
>   Saying something "sucks" without examples and a technical argument is
>   not debate, it is empty rhetoric.

Shrug.  I'm not going to give all the details here in a silly
newsgroup.  Besides, without knowing any of the details, as you admit,
your original comment is basically empyt rhetoric as well.  That's
basically NEWS.

>   I am not talking about that case either, whatever made you think I was?
>   The fact that I said "in the context of the GNAT project"? By that I

Yes.

>   just meant that this was the context of the discussions on how to do
>   things, not that we were talking about special compiler support.

Hmmm, I find that odd.  I'd certainly take advantage of compiler
support in such a context.  Whatever...


/Jon

-- 
Jon Anthony
Synquiry Technologies, Ltd., Belmont, MA 02178, 617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: limited/non-limited in Ada95

[Jon S Anthony]

bobduff@world.std.com (Robert A Duff) writes:

> What's wrong with having:
> 
>     type T is limited private;
> 
> then:
> 
>     type T_Contents is ...; -- not limited!
>     type T is
>         limited record -- to keep Henry from stealing bank accounts ;-)
>             Contents: T_Contents;
>         end record;

Yes, of course, I tried this route.  It makes a mess of things.  To
understand why it makes a mess of things, yes, you'd have to see all
the details, but that's not going to happen under the current
circumstances here...

/Jon

-- 
Jon Anthony
Synquiry Technologies, Ltd., Belmont, MA 02178, 617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: limited/non-limited in Ada95

[Jon S Anthony]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> iRobert Duff said
> 
> <<Well, the rest of the world hasn't seen your GC stuff.  At least I
> haven't.  So I can't quite understand what you're getting at, here.
> What's wrong with having:
> 
>     type T is limited private;
> 
> then:
> 
>     type T_Contents is ...; -- not limited!
>     type T is
>         limited record -- to keep Henry from stealing bank accounts ;-)
>             Contents: T_Contents;
>         end record;>>
> 
> 
> Nothing's wrong with that, it would work fine, despite heated rhetoric
> from people having trouble figuring out how to solve this problem :-)

Of course, you actually have no clue as you have not seen the stuff.

/Jon

-- 
Jon Anthony
Synquiry Technologies, Ltd., Belmont, MA 02178, 617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: limited/non-limited in Ada95

[Robert Dewar]

iRobert Duff said

<<Well, the rest of the world hasn't seen your GC stuff.  At least I
haven't.  So I can't quite understand what you're getting at, here.
What's wrong with having:

    type T is limited private;

then:

    type T_Contents is ...; -- not limited!
    type T is
        limited record -- to keep Henry from stealing bank accounts ;-)
            Contents: T_Contents;
        end record;>>


Nothing's wrong with that, it would work fine, despite heated rhetoric
from people having trouble figuring out how to solve this problem :-)

Re: limited/non-limited in Ada95

[Fergus Henderson]

Jon S Anthony <jsa@synquiry.com> writes:

>bobduff@world.std.com (Robert A Duff) writes:
>
>> What's wrong with having:
>> 
>>     type T is limited private;
>> 
>> then:
>> 
>>     type T_Contents is ...; -- not limited!
>>     type T is
>>         limited record -- to keep Henry from stealing bank accounts ;-)
>>             Contents: T_Contents;
>>         end record;
>
>Yes, of course, I tried this route.  It makes a mess of things.  To
>understand why it makes a mess of things, yes, you'd have to see all
>the details, but that's not going to happen under the current
>circumstances here...

Look, Bob Duff has provided constructive proof that what you want can be done
in Ada 95, and apart from the lines quoted above, the only difference to
your source code will be a few occurrences of ".Contents".  It is clear
that that is not going to "make a mess of things".

So, do you expect us to just take your word for it?
Do you really expect us to believe your word, without a scrap of evidence,
against Robert Dewar's word, and against Bob Duff's word, and more to the
point against Bob Duff's constructive proof?

I for one don't believe you.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: limited/non-limited in Ada95

[Jon S Anthony]

fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:


Oh yeah,

> against Robert Dewar's word, and against Bob Duff's word, and more
> to the

Since when is argument from authority at all relevant here?  Actually,
I don't see any argument here at all - on either side.  As I say, this
is a tradeoff situation where opinion on what is the best of a set of
bad ways to solve something is what is being discussed.


> point against Bob Duff's constructive proof?

What constructive "proof"?  There's nothing I don't/didn't know about
this approach - I even tried it (as _stated_).  This is not about "can
you do this in Ada?"  Of course you can - that's a ridiculous point.

/Jon
-- 
Jon Anthony
Synquiry Technologies, Ltd., Belmont, MA 02178, 617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: limited/non-limited in Ada95

[Jon S Anthony]

fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:

> Look, Bob Duff has provided constructive proof that what you want can be done
> in Ada 95, and apart from the lines quoted above, the only difference to
> your source code will be a few occurrences of ".Contents".  It is clear
> that that is not going to "make a mess of things".

Well, that isn't all there is to it.

Look, I'm not trying to convince you or Bob or Robert or anyone.
Seems much more like you folks are trying to tell me that I should be
positively ecstatic or something about the availability of this sort
of hack and that I should _happily_ use it in constrast to explicitly
forcing reference semantics.

It largely is a matter of _opinion_.  Wrapping non structured
information _just to solve a mechanism problem_ in a structure is IMO
a misleading and inappropriate use of that sort of abstraction and the
supporting construct.  It's a _hack_ as it has _nothing_ to do with
what you are trying to represent.  Period.  It is _equally_ a hack to
use explicit reference semantics.  However, in the latter case, you
are at least using the construct for its _intended_ purpose.  IMO,
that makes it less of a mess.  Both are _messes_ as neither
communicates clearly what is really desired and both cause
"uglification" of the end result.  However, IMO, the wrapping in a
structure approach is a greater mess due to its (IMO) inappropriate
and misleading nature.

> So, do you expect us to just take your word for it?

No.  Why should I?

> Do you really expect us to believe your word, without a scrap of evidence,

No.  Why should I?

> I for one don't believe you.

Fine.  Can you explain to me why I should believe _you_???  Because it
sure sounds like you think I _ought_ to.

/Jon
-- 
Jon Anthony
Synquiry Technologies, Ltd., Belmont, MA 02178, 617.484.3383
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: limited/non-limited in Ada95

[Geert Bosch]

Jon S Anthony <jsa@synquiry.com> wrote:
   It largely is a matter of _opinion_.  Wrapping non structured
   information _just to solve a mechanism problem_ in a structure is IMO
   a misleading and inappropriate use of that sort of abstraction and the
   supporting construct.  It's a _hack_ as it has _nothing_ to do with
   what you are trying to represent.  Period.  

You can also include a component of a volatile type to the structure
you want to pass by reference. This way you avoid an extra layer of
wrapping. The extra component could be declared as
   type Volatile_Type is null record;
   pragma Volatile (Volatile_Type);

   type My_Ref_Passed_Type is record
      Force_By_Reference : Volatile_Type;
      ...
   end record;

I really do not understand how you can find this to be an ugly hack
to force by-reference semantics that limits the possibilities of 
implementing a garbage collector. 

Regards,
   Geert