Creating a high level Pointer API

[Maurizio Cimadamore]

On 09/01/2020 13:13, Ty Young wrote:
>
>
>> Note that MemoryAddress is not meant to be implemented by the user, 
>> and will be made 'sealed' as soon as the sealing support is made 
>> available (by Amber project). So I recommend using aggregation, not 
>> subtyping here (e.g. a Crosspoint has-a MemoryAddress, instead of a 
>> CrossPoint is-a MemoryAddress (and then expose the address with an 
>> accessor, if needed)
>
>
> Is there an actual reason for this or is it "just because"? The 
> ability to plug a Pointer implementation into whatever MemoryAddress 
> argument is kind of a big deal with less boilerplate and all. It kinda 
> waters down the benefit of higher level abstractions...
It's not "just because" - MemoryAddress is a trusted interface, which 
will receive special treatment in some of the C2 optimizations we are 
considering. We want to keep that door open to provide better performances.
>
>
> Frankly, I don't understand what the benefit of "sealing" an interface 
> is - all the code needed to actually implement it is already hidden 
> inside modules. Its not like someone can build a MemoryAddress from 
> scratch.
That's a separate discussion
>
>
>> Seems like a good direction to explore - the fact that you have been 
>> able to come up with something so quickly seems a good sign - e.g. 
>> that the memory access API has the knobs that are needed to build 
>> higher level stuff (which is sort of the claim we're making here).
>
>
> Primitives are easy. I haven't looked at the old Pointer API code but 
> I imagine implemented Struct, Enum, and function callback types are a 
> bit more complicated.
>
>
> How is the new jextract going to handle enums, btw?

Probably like the old one - just ints (higher-level grouping can be 
added, if  needed, via API).

Maurizio