access modes for pointers and memory regions

[Maurizio Cimadamore]

On 22/01/2019 22:45, John Rose wrote:
> My money is on views,
> and the question is whether P+A+MR is too many different
> views or not.  Can we get away with two or even one?
> If so, how does it all factor out?

I agree that is the fundamental question. My line of thinking (which 
prompted my reply) was that if Pointer was a 'real' view (with access 
and all), then MemoryRegion could be our hidden bit of implementation 
which represented _The Memory_ (rather than a view of).

Both API and implementation-wise, I think MemoryRegion is sitting in the 
middle of very important abstractions: Pointer and Arrays on one side, 
and Scope on the other side. It is easy to imagine a world (at least in 
terms of the impl) where there's not even a MemoryRegion thingie 
underneath, and all the relevant info is collapsed one way or another. 
For instance, the base/limit info can be part of the pointer (as these 
are constants), etc.

I like views - and I like (immutable) cursors. But a view that is a 
cursor into another view (which is what Pointer + MemoryRegion seems to 
point to), seems too hard to grasp from an user perspective. Which is 
why I got to the point where MemoryRegion has an intrinsic state 
(R/W/RW) which is likely dictated by the Scope that is used to allocate 
it, and Pointer is a cursor view over that.

As for your other question, whether Arrays and Pointers is one view too 
many, I tried some experiments early this year. In terms of code the 
unification is possible - but I did not like where it all ended up. An 
experimental patch is available here:

http://cr.openjdk.java.net/~mcimadamore/panama/array_pointer_lump/

The main issue with this approach is that you have a carrier like 
Pointer which can either be a true pointer (e.g. an address) or a 
sequence of contiguous objects (e.g. an array) and the only way to query 
for it is to look for the pointer's size presence. I think this is a 
very sneaky lumping move. Also, the semantics of struct field copy for 
arrays and pointer is completely different (arrays are copied in bulk), 
so again collapsing both under the same abstraction feels like a dirty move.

Maurizio