Re: Pass a serial port as user data in a GTK callback handler?

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Randy Brukardt" <randy@rrsoftware.com> 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