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

["Randy Brukardt" <randy@rrsoftware.com>]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcc8ut64uao.fsf@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 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.