* limited/non-limited in Ada95 @ 1997-10-13 0:00 Tom Moran 1997-10-16 0:00 ` Matthew Heaney 0 siblings, 1 reply; 25+ messages in thread From: Tom Moran @ 1997-10-13 0:00 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: limited/non-limited in Ada95 1997-10-13 0:00 limited/non-limited in Ada95 Tom Moran @ 1997-10-16 0:00 ` Matthew Heaney 1997-10-17 0:00 ` Jon S Anthony 1997-10-21 0:00 ` Robert A Duff 0 siblings, 2 replies; 25+ messages in thread From: Matthew Heaney @ 1997-10-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: limited/non-limited in Ada95 1997-10-16 0:00 ` Matthew Heaney @ 1997-10-17 0:00 ` Jon S Anthony 1997-10-18 0:00 ` Matthew Heaney 1997-10-18 0:00 ` Tom Moran 1997-10-21 0:00 ` Robert A Duff 1 sibling, 2 replies; 25+ messages in thread From: Jon S Anthony @ 1997-10-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: limited/non-limited in Ada95 1997-10-17 0:00 ` Jon S Anthony @ 1997-10-18 0:00 ` Matthew Heaney 1997-10-21 0:00 ` Jon S Anthony 1997-10-18 0:00 ` Tom Moran 1 sibling, 1 reply; 25+ messages in thread From: Matthew Heaney @ 1997-10-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: limited/non-limited in Ada95 1997-10-18 0:00 ` Matthew Heaney @ 1997-10-21 0:00 ` Jon S Anthony 1997-10-21 0:00 ` Robert A Duff 1997-10-21 0:00 ` Robert Dewar 0 siblings, 2 replies; 25+ messages in thread From: Jon S Anthony @ 1997-10-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: limited/non-limited in Ada95 1997-10-21 0:00 ` Jon S Anthony @ 1997-10-21 0:00 ` Robert A Duff 1997-10-22 0:00 ` Robert Dewar 1997-10-22 0:00 ` Jon S Anthony 1997-10-21 0:00 ` Robert Dewar 1 sibling, 2 replies; 25+ messages in thread From: Robert A Duff @ 1997-10-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: limited/non-limited in Ada95 1997-10-21 0:00 ` Robert A Duff @ 1997-10-22 0:00 ` Robert Dewar 1997-10-22 0:00 ` Jon S Anthony 1997-10-22 0:00 ` Jon S Anthony 1 sibling, 1 reply; 25+ messages in thread From: Robert Dewar @ 1997-10-22 0:00 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: limited/non-limited in Ada95 1997-10-22 0:00 ` Robert Dewar @ 1997-10-22 0:00 ` Jon S Anthony 0 siblings, 0 replies; 25+ messages in thread From: Jon S Anthony @ 1997-10-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: limited/non-limited in Ada95 1997-10-21 0:00 ` Robert A Duff 1997-10-22 0:00 ` Robert Dewar @ 1997-10-22 0:00 ` Jon S Anthony 1997-10-23 0:00 ` Fergus Henderson 1 sibling, 1 reply; 25+ messages in thread From: Jon S Anthony @ 1997-10-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: limited/non-limited in Ada95 1997-10-22 0:00 ` Jon S Anthony @ 1997-10-23 0:00 ` Fergus Henderson 1997-10-23 0:00 ` Jon S Anthony 1997-10-23 0:00 ` Jon S Anthony 0 siblings, 2 replies; 25+ messages in thread From: Fergus Henderson @ 1997-10-23 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: limited/non-limited in Ada95 1997-10-23 0:00 ` Fergus Henderson @ 1997-10-23 0:00 ` Jon S Anthony 1997-10-24 0:00 ` Geert Bosch 1997-10-23 0:00 ` Jon S Anthony 1 sibling, 1 reply; 25+ messages in thread From: Jon S Anthony @ 1997-10-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: limited/non-limited in Ada95 1997-10-23 0:00 ` Jon S Anthony @ 1997-10-24 0:00 ` Geert Bosch 0 siblings, 0 replies; 25+ messages in thread From: Geert Bosch @ 1997-10-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: limited/non-limited in Ada95 1997-10-23 0:00 ` Fergus Henderson 1997-10-23 0:00 ` Jon S Anthony @ 1997-10-23 0:00 ` Jon S Anthony 1 sibling, 0 replies; 25+ messages in thread From: Jon S Anthony @ 1997-10-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: limited/non-limited in Ada95 1997-10-21 0:00 ` Jon S Anthony 1997-10-21 0:00 ` Robert A Duff @ 1997-10-21 0:00 ` Robert Dewar 1997-10-21 0:00 ` Jon S Anthony 1 sibling, 1 reply; 25+ messages in thread From: Robert Dewar @ 1997-10-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: limited/non-limited in Ada95 1997-10-21 0:00 ` Robert Dewar @ 1997-10-21 0:00 ` Jon S Anthony 1997-10-22 0:00 ` Robert Dewar 0 siblings, 1 reply; 25+ messages in thread From: Jon S Anthony @ 1997-10-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: limited/non-limited in Ada95 1997-10-21 0:00 ` Jon S Anthony @ 1997-10-22 0:00 ` Robert Dewar 1997-10-22 0:00 ` Jon S Anthony 0 siblings, 1 reply; 25+ messages in thread From: Robert Dewar @ 1997-10-22 0:00 UTC (permalink / raw) <<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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: limited/non-limited in Ada95 1997-10-22 0:00 ` Robert Dewar @ 1997-10-22 0:00 ` Jon S Anthony 0 siblings, 0 replies; 25+ messages in thread From: Jon S Anthony @ 1997-10-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: limited/non-limited in Ada95 1997-10-17 0:00 ` Jon S Anthony 1997-10-18 0:00 ` Matthew Heaney @ 1997-10-18 0:00 ` Tom Moran 1997-10-18 0:00 ` Matthew Heaney 1 sibling, 1 reply; 25+ messages in thread From: Tom Moran @ 1997-10-18 0:00 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: limited/non-limited in Ada95 1997-10-18 0:00 ` Tom Moran @ 1997-10-18 0:00 ` Matthew Heaney 1997-10-19 0:00 ` Tom Moran 1997-10-21 0:00 ` Robert A Duff 0 siblings, 2 replies; 25+ messages in thread From: Matthew Heaney @ 1997-10-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: limited/non-limited in Ada95 1997-10-18 0:00 ` Matthew Heaney @ 1997-10-19 0:00 ` Tom Moran 1997-10-19 0:00 ` Matthew Heaney 1997-10-21 0:00 ` Robert A Duff 1 sibling, 1 reply; 25+ messages in thread From: Tom Moran @ 1997-10-19 0:00 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: limited/non-limited in Ada95 1997-10-19 0:00 ` Tom Moran @ 1997-10-19 0:00 ` Matthew Heaney 1997-10-21 0:00 ` Tom Moran 0 siblings, 1 reply; 25+ messages in thread From: Matthew Heaney @ 1997-10-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: limited/non-limited in Ada95 1997-10-19 0:00 ` Matthew Heaney @ 1997-10-21 0:00 ` Tom Moran 1997-10-21 0:00 ` Matthew Heaney 0 siblings, 1 reply; 25+ messages in thread From: Tom Moran @ 1997-10-21 0:00 UTC (permalink / raw) >>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. :( ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: limited/non-limited in Ada95 1997-10-21 0:00 ` Tom Moran @ 1997-10-21 0:00 ` Matthew Heaney 0 siblings, 0 replies; 25+ messages in thread From: Matthew Heaney @ 1997-10-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: limited/non-limited in Ada95 1997-10-18 0:00 ` Matthew Heaney 1997-10-19 0:00 ` Tom Moran @ 1997-10-21 0:00 ` Robert A Duff 1 sibling, 0 replies; 25+ messages in thread From: Robert A Duff @ 1997-10-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: limited/non-limited in Ada95 1997-10-16 0:00 ` Matthew Heaney 1997-10-17 0:00 ` Jon S Anthony @ 1997-10-21 0:00 ` Robert A Duff 1 sibling, 0 replies; 25+ messages in thread From: Robert A Duff @ 1997-10-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~1997-10-24 0:00 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-10-13 0:00 limited/non-limited in Ada95 Tom Moran 1997-10-16 0:00 ` Matthew Heaney 1997-10-17 0:00 ` Jon S Anthony 1997-10-18 0:00 ` Matthew Heaney 1997-10-21 0:00 ` Jon S Anthony 1997-10-21 0:00 ` Robert A Duff 1997-10-22 0:00 ` Robert Dewar 1997-10-22 0:00 ` Jon S Anthony 1997-10-22 0:00 ` Jon S Anthony 1997-10-23 0:00 ` Fergus Henderson 1997-10-23 0:00 ` Jon S Anthony 1997-10-24 0:00 ` Geert Bosch 1997-10-23 0:00 ` Jon S Anthony 1997-10-21 0:00 ` Robert Dewar 1997-10-21 0:00 ` Jon S Anthony 1997-10-22 0:00 ` Robert Dewar 1997-10-22 0:00 ` Jon S Anthony 1997-10-18 0:00 ` Tom Moran 1997-10-18 0:00 ` Matthew Heaney 1997-10-19 0:00 ` Tom Moran 1997-10-19 0:00 ` Matthew Heaney 1997-10-21 0:00 ` Tom Moran 1997-10-21 0:00 ` Matthew Heaney 1997-10-21 0:00 ` Robert A Duff 1997-10-21 0:00 ` Robert A Duff
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox