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: border1.nntp.dca3.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!ottix-news.ottix.net!newsswitch.lcs.mit.edu!nntp.TheWorld.com!.POSTED!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Ada202X: Easy to use "UML private"-like components Date: Mon, 24 Jun 2013 20:43:54 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <69246de0-4b33-4d47-b5be-a45e8c911fb0@googlegroups.com> <9qrbs8l828t3pvgves504a8fm7o1c7tcpj@4ax.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls6.std.com 1372121034 23319 192.74.137.71 (25 Jun 2013 00:43:54 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Tue, 25 Jun 2013 00:43:54 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:I8JHx2CfDXTA6WBJYBX2GcH+zVE= X-Original-Bytes: 3026 Xref: number.nntp.dca.giganews.com comp.lang.ada:182076 Date: 2013-06-24T20:43:54-04:00 List-Id: 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. - Bob