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!backlog4.nntp.dca3.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!goblin3!goblin.stu.neva.ru!nntp-feed.chiark.greenend.org.uk!ewrotcd!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: Pass a serial port as user data in a GTK callback handler? Date: Wed, 19 Feb 2014 18:34:43 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <050a1b45-c312-4fff-96f9-7c3d01466500@googlegroups.com> <58fb9abc-1892-4a36-9895-c494dbc727c9@googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1392856485 19253 69.95.181.76 (20 Feb 2014 00:34:45 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 20 Feb 2014 00:34:45 +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 X-Original-Bytes: 6726 Xref: number.nntp.dca.giganews.com comp.lang.ada:185018 Date: 2014-02-19T18:34:43-06:00 List-Id: "Robert A Duff" wrote in message news:wcc8ut64uao.fsf@shell01.TheWorld.com... > "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 see. > 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). Not just the magical properties, but also the simple fact that you can't even make them *look* the same. I wanted to allow/encourage "all" in their syntax in order that they at least *look* like general access types, making the existing syntax obsolescent. But I didn't get much support for that. So now we have the weird situation that you have to have "all" to use 'Access with a named access type, but you must NOT use "all" with an anonymous access type. Bah! > 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. Yeah, you got rid of the term collection in Ada 95, and we just now put it back in Ada 2012. So I think you were confused for a fairly long moment - a bit under 17 years. :-) If we had left it around, things would be better. Note that pool-specific access types are a bit safer in general, because you can (with effort, admittedly not usually done) make deallocation safe. Whereas with general access, even if you have a valid (non-dangling) access object, you can't figure out whether it is safe (and necessary) to deallocate it or if you should just drop it on the floor. And if you get that wrong, you have storage leaks or erroneous execution. At least in Ada 2012 you can create a convinient smart pointer abstraction that takes care of all of that. Probably we ought to have considered adding such a thing to the standard library. >> 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). That's true in theory, but as a practical matter trying to force alignment on I/O was too expensive to contemplate. Unfortunately, practice can screw up a lot of otherwise good ideas. > And anyway, I would expect an int* > on such a machine to be represented by a word-aligned address. You'd be wrong about that. They tried that, and no existing C code (especially Unix) would work. That's one of those functional requirements that don't show up in a language standard. They ended up making all C pointers byte-pointers. And of course we had to interface to that existing compiler, especially since our target was their POSIX emulation (as opposed to their raw OS). > And you can convert from pool-specific to general, so whatever your > representation is, it must allow for that. Yes, but that's easy: just add a byte pointer to byte 0. Converting in the other direction is not possible in general, because dropping a non-zero byte-pointer would lead to reading and writing the wrong memory. >> 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. Right. We couldn't of course do that in our Z-80 compiler (this check was inserted essentially at day 1 for Janus/Ada, because we were having a lot of trouble with uninitialized pointers). It's probably less useful now than it once was (the heap being a fairly large part of the address space), but I've never wanted to lose functionality going forward. >> 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. But it sure would help if named and anonymous access used the same syntax. :-) Randy.