Re: Dispatching callback handed over to C

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

"Natasha Kerensikova" <lithiumcat@gmail.com> wrote in message 
news:slrnjnnvk6.1lme.lithiumcat@sigil.instinctive.eu...
...
>>                                                and prevents the compiler
>> optimizer for working at all (it has to assume the worst about any object 
>> in
>> your program, unless it is willing to completely trash your program).
>
> That was another question I had in mind with that mechanism: I'm giving
> to C a reference to Ada data in one call (namely Event_New) but it gets
> used later, in another call (to Event_Base_Dispatch) which seeming does
> not involve the data at all.
>
> Should go to some extra steps (but which?) to warn the compiler that my
> Event object can change during Event_Base_Dispatch call despite that
> call not involving any Event object?
> Or maybe just marking the Event object as aliased is enough?

Aliased should be enough (Ada 95 suggests that it be used for this purpose). 
Some compilers don't insist on this (mostly because of Ada 83 code 
compatibility concerns), but I presume that they figure this out via some 
other mechanism (probably the same one that C compilers use, which typically 
is fiendishly complicated and rather prone to bugs).

>> The whole idea of the void pointer is so anti-Ada that it is best to get 
>> rid
>> of it as early as you can. (There is no such thing as "untyped data" in 
>> Ada,
>> and, as Dmitry likes to point out, not in real life, either. There is 
>> only
>> data for which the type is not known at compile-time, and that sort of 
>> data
>> is a problem - best to avoid it.)
>
> I feel you are being a bit unfairly harsh towards void pointers here: it
> looks to me that you are looking at them in a purely Ada context, which
> is about as incorrect as coding in Ada with another language in mind and
> complaining about being forced to fight the compiler.

Well, we're talking about Ada here, and what we have to do to interface to 
some foreign language API. I'm not interested in writing C - in any syntax!

> In C, void pointer is not really about untyped data, but data whose type
> is actively treated with agnosticism.
> Transposed to Ada world, it's like saying it does not make sense to
> have a record whose components are unknown, and in real life there is no
> such thing as a record with unknown components. "private" is only about
> preventing client from depending on component information rather than
> "void"ing components.

The void pointer is C is about data where the C type system isn't strong 
enough to describe it. So it simply throws away all of the type information, 
leaving you with none. The data itself surely has a type, but you can't use 
any knowledge about it. OTOH, the richer Ada type system often *can* 
describe this data, and in such a case, you will want to do that. (Yes, 
there are cases where Ada can't describe it, either - but I generally think 
those require a redesign, not a hack.)

An obvious example is the access-to-class-wide that Mariej was talking 
about. Clearly Ada can describe this, so you want to avoid using "void" in 
your (Ada) interface.

>>                                   In Claw, we tried to avoid void by 
>> simply
>> defining the interfaces for the types we cared about. For instance, if we
>> needed to read an array of stream elements, we'd define the API using 
>> that
>> type (rather than void). In other cases, we defined a void type (as 
>> access
>> to something) and used Unchecked_Conversions as needed to make it
>> crystal-clear this is wildly unsafe. Obviously, you have to do something 
>> to
>> interface to mindless APIs, but you have to hide them as quickly as
>> possible.
>
> That's exactly what I'm trying to do. Void pointers are indeed anti-Ada,
> because Ada rather uses generic formal types or tagged types or
> interfaces. The whole art of designing bindings is, in my opinion, to
> expose an interface as Ada-ish as possible despite the underlying
> anti-Ada stuff.

Absolutely. The really low-level stuff is likely to be grungy and not 100% 
portable. But that's OK, so long as it is localized as much as possible. 
(Pragmatism has to trump goodness -- if the binding doesn't work, it doesn't 
matter how "good" it is!)

                                        Randy.