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,5606d8433901738c X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Allocating "initialized" limited types... Date: 1996/09/05 Message-ID: #1/1 X-Deja-AN: 178547313 references: organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-09-05T00:00:00+00:00 List-Id: In article , Jon S Anthony wrote: >> The two cases of initialization are entirely analogous. In the second >> case, the heap object is being explicitly initialized. Look at the >> rules in the RM for the two cases -- you will see a lot of parallels, >> and that's intentional. > >Sure, that is indeed how the RM talks about these cases. Doesn't make >it "right". True, it doesn't make it right, but I think it *is* right, nonetheless. Your complaint was, you can't initialize a limited heap variable in a way that prevents you from forgetting some components. Initializing with an aggregate gives that nice feature, but it doesn't work for limited types. A valid complaint, perhaps, but it's equally valid for stack objects. >... The second case is simply one where the idea of the heap >object being first created, then the expression being converted to >type T and then the heap object being assigned the resulting value is >an internal language design issue. Actually, the expression is evaluated first, since it's discriminants or bounds might determine what to create. Then the object is created. >... Joe Programmer didn't ask for >those semantics. It is not even clear that they are all that good a >semantics for this case. In fact, it is not even clear that thinking >of this as an _initialization_ is even the best way of thinking of it. >They were deemed good and proper by the designer - presumably for >perceived "consistency" or "regularity" reasons - or something. > >J.Progammer: > >"Hey, I'm creating an object with those values - I'm not creating an >object first and then _initializing_ it after the fact with those >values." This isn't peculiar at all - it is very similar to what >happens with a discriminant constraint. Fine. All I was saying is that the same arguments apply equally to both "new T'(...)" and "X: T := ...;". >So, the "not" refers to the fact that with access to class wide types >the "structure equivalent" semantics _are_ what you get. _One_ named >type being allowed to refer to whole sets of possible structures. Not quite. For named access-to-class-wide types, you get named equivalence. For anonymous access-to-class-wide types, you get structural equivalence. And the latter is only allowed in certain cases (parameters and discriminants). >I think we just talked past one another (each missing the other's >point) - such is news... ;-) >> Perhaps we should have defined access-to-tagged to allow implicit >> conversions up the hierarchy. It's a bit tricky to get the overload >> resolution rules right, so they don't cause Beaujolais effects, but I >> think it's possible. > >That would have been nice for the user - but as you say, tricky to get >right. Ah, well. >> (By the way, we should not have defined the "access all" feature. We >> should have just made all access types work that way. There's really no >> *important* reason for the language to have both "access Foo" and >> "access all Foo". This design mistake was largely my fault -- during >> the language design, I argued strongly for the "all" feature. I've >> since changed my mind, since I end up almost always using "all" anyway.) > >Yes, that was a goof. But an understandable one and with good >reasons. This is the sort of thing that is hard to get right without >actual field use in real applications. I suppose you could've lucked >out if you'd have turned it around. Having had the "all" semantics be >the default and then required some indication for the case where >specialized pools were going to be used. That way, the (supposed) >special indicator wouldn't have become what has turned out to be by >far the common one. True, but the non-all syntax matches what Ada 83 does, so it was natural to leave that alone, and add on the "all" syntax meaning "you can do conversions when you couldn't in Ada 83". Anyway, typing "all" all the time is a very minor annoyance -- what annoys me more is have two features in the language, where one would suffice. - Bob