Re: "out" or "access"

[Robert A Duff <bobduff@world.std.com>]

Matthew Heaney <matthew_heaney@acm.org> writes:

> Robert A Duff <bobduff@world.std.com> writes:
> 
> > Perhaps you should have two different sorts of iterators, one that can
> > modify, and one that can't.
> 
> Yes, I thought of that too, but I was trying to keep things simple.

Too simple?

> > > So perhaps I'm going beyond what even access constant params buy you.
> > > Maybe my real problem is how to "cast away const."
> > 
> > Sounds dangerous.
> 
> "const" in the sense of in param:
> 
>    function Set_Top
>      (Stack : Stack_Type)
>      return Item_Access is
> 
>       SA : constant Object_Pointer :=
>         To_Pointer (Stack'Address);
>    begin
>       pragma Assert (Stack.Length > 0);
>       return SA.Items (Stack.Top)'Access;
>    end Set_Top;
> 
> So the client can:
> 
>    Set_Top (Stack).all := 10;

But this allows clients to write upon constants, which sounds like a Bad
Thing.

> Of course, here it's not strictly necessary, since I can declare Set_Top
> to take an access parameter.
> 
> The "const" thing is the entity passed as the in-param of the function
> call.  In my case, the entities are always tagged, and so are aliased,
> and so taking the address is well-defined.

But writing upon constants is not.

> The behavior I'm thinking of is analogous to what happens when you call
> function Random of the random number generator.

...which is pretty ugly, IMHO.

> Essentially, I'm trying to get around Ada's lack of in out params for
> functions.  How does the Ada programmer implement his own abstractions
> whose functions have state-changing behavior -- like Random does?

I wish functions allowed 'in out' params.

In the absence of that, you can do the Random trick, but that's kind of
messy.  I'd suggest an explicit access type instead.

> Yes, yes, I know you can implement the abstraction as a controlled
> record containing a pointer to the "real" data, but I was investigating
> cheaper alternatives.
> 
> Why is the RM so silent on intended uses of package
> System.Address_To_Access_Conversions?

Because the RM isn't a text book, I guess.

> I should have asked, How do the language designers intend Ada programmers
> to implement a side-effect producing function, whose param (of mode in)
> is a tagged type?

I think the language designers intend that you shouldn't do that.

As far as the language design issue goes, I'm on your side -- 'in out'
should be allowed in functions.  But since it isn't, I wouldn't resort
to the extreme trickery you suggest.

> When I do this:
> 
>    function Set_Top (Stack : Stack_Type) return Item_Access is
>    begin
>       ... Stack'Access ...
> 
> this gives me an access-to-constant view.  I want an access-to-variable
> view. 
> 
> I wasn't trying to change a "constant," in the sense of a constant
> object declaration (which isn't possible for limited types anyway), but
> rather I was trying to turn a constant view --of an otherwise modifiable
> object-- into a variable view.

I would suggest you either pass explicit access values, or else give up
on functions and use procedures.

> I would be really swell if we had constructors too, not just functions
> trying to do the job.  The latter technique doesn't work for limited
> types.

That was my point -- *initializing* a limited object with a function
call should not be illegal.  It's assigning them around after that that
causes trouble.  Likewise, an aggregate of a limited type could make
perfect sense, if it's only used to *initialize* an object.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.