[foreign] rethinking Panama annotations

[Jorn Vernee]

This seems fine to me, after all Callbacks are a carrier for function 
pointers, so @NativeCallback declaring the layout of a function pointer 
seems to make sense from a user perspective as well.

Just so we're clear, wouldn't the use site of Layout-Based actually be 
`qsort=(u64: i32 i32 ${qsortComp})v` instead of `qsort=(u64: i32 i32 
u64:${qsortComp})v` (so without the u64:)?

Also, `Layout.of("u64:(i32 i32)(qsortComp)i32")` is not parsing for me, 
I have to use `Layout.of("u64(qsortComp):(i32 i32)i32")`, and then the 
name correctly appears on the returned layout as well.

Jorn

Maurizio Cimadamore schreef op 2018-11-26 18:56:
> 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