[foreign] rethinking Panama annotations

[Maurizio Cimadamore]

On 26/11/2018 14:15, Maurizio Cimadamore wrote:
> separate patch for adding support for descriptor name resolution in 
> callbacks

I've been thinking more about this, and it's not as easy as it looks at 
first...

The issue is that if we want to support resolution for both struct names 
and callback names, that means that Unresolved essentially becomes a 
'descriptor', not a layout. But if we pull on this string more, then we 
need to replace descriptor for layout everywhere in the API, de facto 
flattening the API (e.g. clients will be using descriptor everywhere, 
thus making the descriptor vs. layout split useless).

The only way I see to support name resolution for callbacks and, at the 
same time, retain the descriptor vs. layout split, is to tweak the 
@NativeCallback annotation so that its value attribute describes a full 
address layout, not just the signature of the callback - e.g.


	Vanilla
	Descriptor-based
	Layout-based
Declaration
	@NativeCallback("(i32 i32)i32")
interface QsortComp { ... } 	@NativeCallback("(i32 i32)(qsortComp)i32")
interface QsortComp { ... } 	@NativeCallback("u64:(i32 i32)(qsortComp)i32")
interface QsortComp { ... }
Use-site
	qsort=(u64:[0i32]i32i32u64:(u64:i32u64:i32)i32)v
	qsort=(u64: i32 i32 u64:${qsortComp})v 	qsort=(u64: i32 i32 
u64:${qsortComp})v

So, first notice how much compaction we get by being able to refer to 
callbacks by name - the use site values in the second and third column 
are clearly more legible than the one in the first column, in which tne 
entire callback signature has to be repeated (which is also error prone, 
if you write these things by hand).

The difference between descriptor-based and layout-based is that in the 
former, we are able to refer to a function descriptor directly using an 
unresolved hole; in the latter case, the unresolved hole will resolve to 
a layout (an address layout whose pointee is a function). Therefore, the 
layout-based approach preserves all the properties we care about: it 
allows to retain the distinction between layouts and functions, while at 
the same time allowing for some for of by-name reference for callbacks. 
The small price to pay is that the contents of the @NativeCallback 
annotation will now contain not just the callback signature, but the 
full address layout corresponding to a function pointer associated to 
that callback.

Is this something that we consider acceptable?

Cheers
Maurizio