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!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!peer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!nntp.club.cc.cmu.edu!micro-heart-of-gold.mit.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!.POSTED!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Pass a serial port as user data in a GTK callback handler? Date: Wed, 19 Feb 2014 17:22:23 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <050a1b45-c312-4fff-96f9-7c3d01466500@googlegroups.com> <58fb9abc-1892-4a36-9895-c494dbc727c9@googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls7.std.com 1392848547 870 192.74.137.71 (19 Feb 2014 22:22:27 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Wed, 19 Feb 2014 22:22:27 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:q1uirkGq+JRmAx325Dx21r6LtoI= X-Received-Bytes: 3687 X-Received-Body-CRC: 983520323 Xref: news.eternal-september.org comp.lang.ada:18683 Date: 2014-02-19T17:22:23-05:00 List-Id: "Randy Brukardt" writes: > Fascinating. I wouldn't consider that wrong; the problem is the > inconsistency with anonymous access types (which would be easily solved by > not introducing them in the first place. ;-). What Ada calls general access > and pool-specific access types ought to be separated somehow. I agree that there is some value in distinguishing general from pool-specific access types. But it comes at a cost in language complexity -- we commonly see programmers getting confused by it. So I ended up concluding that the language would be better off (simpler) if all access types were general, and you can't say "access all". I also agree that the inconsistency with anonymous access types exacerbates the problem. Anonymous access types should be a simple short-hand for what you get if you declare a named access type in the usual place. Unfortunately, they have all sorts of magical properties (coextensions, dynamic accessibility, etc). The term "pool-specific" is a misnomer, by the way. That's also my fault -- I was momentarily confused into thinking that a "storage pool" and a "collection" are the same thing. Perhaps they should be, but they're not in Ada. > Requiring the representation of all access types to be the same would force > pool-specific types to have a worse representation than otherwise > necessary -- on the U2200, general access types had to include byte-pointers > (for C compatibility), but pool-specific types could assume word alignment. > That was a substantial performance difference. I don't understand that. Access types don't need to be C-compatible unless you say Convention(C). And anyway, I would expect an int* on such a machine to be represented by a word-aligned address. And you can convert from pool-specific to general, so whatever your representation is, it must allow for that. > Janus/Ada also uses stronger checking on pool-specific types (for an access > type using the standard pool, if the value isn't inside the pool, we raise > an exception rather than trash memory). Can't do that for general access > types. At some efficiency cost, you can check for dangling pointers, which is even better than what you say above. Well, "better" in catching bugs, but probably a lot worse in terms of efficiency. > I suppose we could have used an aspect for the difference (if we had had > aspects in 1993), but having legality depend on aspects is always a bit > dodgy. Yes, if the distinction is to be made, I have no problem using the "access all" syntax for that. - Bob