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.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!mx05.eternal-september.org!feeder.eternal-september.org!news.stack.nl!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada202X: Easy to use "UML private"-like components Date: Tue, 25 Jun 2013 14:23:02 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <69246de0-4b33-4d47-b5be-a45e8c911fb0@googlegroups.com> <9qrbs8l828t3pvgves504a8fm7o1c7tcpj@4ax.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1372188184 22344 69.95.181.76 (25 Jun 2013 19:23:04 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 25 Jun 2013 19:23:04 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:15933 Date: 2013-06-25T14:23:02-05:00 List-Id: "Robert A Duff" wrote in message news:wccli5zqat1.fsf@shell01.TheWorld.com... > Niklas Holsti writes: > >> That seems likely to create program-portability problems - on a 64-bit >> machine, a 64-bit record could be opaque, but it could not be opaque on >> a 32-bit machine (unless all pointers are artificially made 64 bits >> wide, too). > > Yes. I was appalled by that feature for exactly that reason. > I'm a big fan of portability. > > But given the time frame of Modula-2, I think your example should be > 16-bit/32-bit not 32/64. ;-) > > In any case, in plain English, "opaque" doesn't have all these > pointer/heap implications, so I suggest saying something like > "Modula-2-style opaque types" rather than just "opaque types" > if that's what you mean. > >> The main difference is that in Ada, the unknown underlying type is named >> -- what you call the stt-incomplete type. This type is of course >> invisible to the users (clients) of the private type. Off hand, it does >> not seem to me that such named-but-incomplete types should cause hard >> problems for the compiler, but it appears that you have experienced such >> problems. Perhaps they did not exist in Ada 83, but came about because >> of other extensions such as controlled types? > > The implementation problems existed in Ada 83. I'm not sure I remember > all the issues, but the most obvious is that there's an implicit > assumption that you can tell the size/representation of a pointer > without knowing what it points at. There are various reasons that might > not be true. In fact, it's not true in GNAT. > > Also, I think it was legal to do "X.all" on those things (in the package > spec) in Ada 83. It would always raise Constraint_Error, but the > "natural" implementation wants to know the size of X.all. I fixed that > in Ada 95 by changing the freezing rules to make it illegal, IIRC. I think there was also an issue with constraints in Ada 83 that was fixed in Ada 95. Note that stt-incomplete types were the basis for the "limited with" feature in Ada 2007, so it's not like the language designers have neglected the feature. (We thought that if stt-incomplete already worked, implementers couldn't complain about limited with - that turned out not to be quite true.) Randy.