From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9a7e0c43216f4def X-Google-Attributes: gid103376,public From: Robert A Duff Subject: Re: "out" or "access" Date: 1998/11/01 Message-ID: #1/1 X-Deja-AN: 407356598 Sender: bobduff@world.std.com (Robert A Duff) References: <908956499.754394@dedale.pandemonium.fr> <70mo3h$gll$1@cf01.edf.fr> <71cjab$ka8$1@nnrp1.dejanews.com> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1998-11-01T00:00:00+00:00 List-Id: Matthew Heaney writes: > Robert A Duff 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.