Design thread for from end slicing

[dsyme]

[dsyme]

@TIHan, @cartermp and @dsyme had a design discussion today about from end slicing in F# (currently in preview). Design notes are below.

Context: There is a dissonance between the C# 9.0 design for slicing and indexing and the existing F# support.

F# support for multi-dimensional indexing and slicing looks like this:

// F# pattern
type Tensor with

    // 1D
    member t.Item(i:int) =
    member t.GetSlice(i0min:int option, i0max:int option) =

    // 2D
    // xs.[a, b]
    member t.Item(i:int, j:int) =
    // xs.[a..b, c..d]
    member t.GetSlice(i0min:int option, i0max:int option, i1min:int option, i1max:int option) =
    // xs.[a..b, c]
    member t.GetSlice(i0min:int option, i0max:int option, i1:int) =
    // xs.[a, b..c]
    member t.GetSlice(i0:int, i1min:int option, i1max:int option) =

The F# support has problems:

1. exponential expansion makes > 5 dim hard

2. int64 indexing sucks

3. the allocation of options require advanced knowledge of inlining techniques + multiple additional API entrypoints to remove those through compiler optimizations

4. doesn't interop with C# Index/Range APIs

Here we address 4, and coincidentally 3.

The F# proposal is to adjust FS-1076 as follows:

1. Change GetReverseIndex transformation se we have:

   xs.[ 2 ] --> xs.Item(2)
   xs.[ ^2 ] --> xs.Item(Index(2,true))
   

   For slicing prefer .get_Item if no GetSlice exists, inserting Range and Index as necessary:
   xs.[ 3.. ^2 ] ==> xs.get_Item(Range(Index(3,false), Index(2, true)))
   xs.[ 3, 4..5 ] ==> xs.get_Item(Index(3,false), Range(Index(4,false), Index(5+1, false)))

   If there is a GetSlice then:
   xs.[ 3.. ^2 ] ==> xs.GetSlice(Some 3, Index(2,true)))

2. Advise F# people to design to get_Item/Index/Range, see below

Note that in the above ^e always becomes Index(e, true) in indexer notation. GetReverseIndex is removed.

Note this only solve problem 3 and 4.

Note these equivalences:

    F#: xs[ 3, 4..5 ] 
    C#: xs[ 3, 4..6 ] 

    F#: xs[ 0.. ] 
    C#: xs[ 0.. ] 

    F#: xs[ 0.. ^0 ] 
    C#: xs[ 0.. ^0 ] 

    F#: xs[ 4.. ^2 ] 
    C#: xs[ 4.. ^2 ] 

In future F# pattern becomes same as C# pattern:

     type Tensor with
         // 1D
         member t.Item(i:int) =
         member t.Item(i:Index) =
         member t.Item(i:Range) =

         // 2D
         member t.Item(i:int, j:int) =
         member t.Item(i:Index, j:Index) = ...
         member t.Item(i:Index, j:Range) = ...
         member t.Item(i:Range, j:Index) = ...
         member t.Item(i:Range, j:Range) = ...
    etc.

Note it is possible to add from-end-indexing-and-slicing to 1D F# types like FSharpList<'T> that have GetSlice by adding these two methods:

type List<T> with
    member t.Item(i:int) =
    member t.Item(i:Index) =  // new
    member t.GetSlice(i0s:Range) = // new
    member t.GetSlice(startIndex:int option, endIndex:int option) -> 'T list  

[dsyme]

There are issues with the above design change which I noticed while writing up the notes

It requires overloading the Item property which is unfortunate for F# type inference, as for this:

let f (xs:Tensor) i = xs.[i]

you will need a type annotation of (i: int) or (i:Index) to resolve the potential ambiguity for get_Item(i:Range)

Also, the F# programmer might reasonably want to keep the slicing methods separately named to the get_Item method but switch to using Index/Range instead of the current F# encoding.

That is there is question about whether we support the following for F# coding:

     type Tensor with
         // 1D
         member t.Item(i:int) =
         member t.Item(i:Index) =
         member t.GetSlice(i:Range) =

         // 2D
         member t.Item(i:int, j:int) =
         member t.Item(i:Index, j:Index) =
         member t.GetSlice(i:Index, j:Index) = ...
         member t.GetSlice(i:Index, j:Range) = ...
         member t.GetSlice(i:Range, j:Index) = ...
         member t.GetSlice(i:Range, j:Range) = ...
    etc.

[gusty]

Can't we use something like trait-calls defaults to make indexing operations default to int in absence of type annotations and evidence from usage ?

[Happypig375]

Or just de-prioritise Index and Range overloads.