Interfaces with static abstract members (IWSAMs) [RFC-1124]

[smoothdeveloper]

Opening the can of cans of discussions.

Suggestion: fsharp/fslang-suggestions#1151
RFC: https://github.com/fsharp/fslang-design/blob/main/FSharp-7.0/FS-1124-interfaces-with-static-abstract-members.md

[Happypig375]

Forget cans of worms. Behold! The cans of cans!

[smoothdeveloper]

I didn't foresee the thread would have such amount of engagement 😄, hence behold the cans of cans of discussions!

[krauthaufen]

Hey, I'm aware that the interface list for double is just ridiculous, but I don't see how it introduces overhead inf terms of runtime, since I expected static interface methods to be resolved JIT-time (maybe I'm wrong there since that would mean having separate code for all types and not only for structs)

Personally i was down over-abstraction road in haskell with redefining all the basic type-classes holding one single function each where * ended up being 'a -> 'b -> 'c with functional dependencies/type families in order to allow for vector/matrix logic etc. so I totally get your point there.

Nonetheless I think (when used carefully) this could be a great tool for mathematical stuff and should not end up being treated as a second-class-citizen in F#

[smoothdeveloper]

I am thinking the overhead described is the compile time one, where type checking has to parse several types and resolve unambiguously.

[dsyme]

I've added two sections to the RFC here: https://github.com/fsharp/fslang-design/blob/main/RFCs/FS-1124-interfaces-with-static-abstract-members.md#self-type-constraints

[Lanayx]

let inline f<^T when WithBoth<^T>>() =
    let v1 = 'T.StaticProperty
    let v2 = 'T.StaticMethod(3)
    v1 + v2

This syntax is very confusing. It will be also inconvenient to refactor (rename the type), also can be glitches when function is defined inside parametrized class:

type Test<'T>() =
  let inline f<^T when WithBoth<^T>>() =
      let v1 = 'T.StaticProperty
      let v2 = 'T.StaticMethod(3)
      v1 + v2
      
  member this.X = ()
      

[vshapenko]

I would propose to recognize ' as ^ in lexer, when inline keyword is declared

[vzarytovskii]

let inline f6<'T when 'T : (static member Foo: 'T * 'T -> 'T)>(x: 'T, y: 'T) =
	'T.Foo(x, y)

Should resolve as static (infer staticness from the constraint).

[Lanayx]

I also wanted to suggest supporting flexible types e.g. ability to write

let getZero<#INumber<'T>> () =
    'T.Zero

instead of

let getZero<'T when 'T:>INumber<'T>> () =
    'T.Zero

The currently suggested syntax

let getZero<'T when INumber<'T>> () =
    'T.Zero

is not short enough and also have a downside of having to learn smth new, while flexible types are well-known concept

[vzarytovskii]

@NinoFloris

let M<'TValue when 'TValue :> IComparable and ICloneable and IDisposable>() = 

This should work now in the new PR:

type IStaticProperty<'T when 'T :> IStaticProperty<'T>> =
    static abstract StaticProperty: 'T

type IStaticMethod<'T when 'T :> IStaticMethod<'T>> =
    static abstract StaticMethod: 'T -> 'T
    
let foo<'T when IStaticProperty<'T> and IStaticMethod<'T>>() = ()

[vzarytovskii]

Does not work with interfaces which don't have type arguments though.

[vzarytovskii]

You can do something like this though:

type IFoo<'T when 'T :> IDisposable and  'T :> IEnumerable> = 'T
let foo<'T when IFoo<'T>>() = ()

Not sure if this is intended @dsyme.

[NinoFloris]

This should work now in the new PR:

Nice! (I assume this is the active branch? https://github.com/dotnet/fsharp/pull/13119/commits)

Does not work with interfaces which don't have type arguments though.

When I can do one I would expect to be able to do the other as well. IMO F# already has plenty of orthogonality issues at the syntax level. So not sure how I feel about having to hacking around it with an alias.

[vzarytovskii]

Nice! (I assume this is the active branch? https://github.com/dotnet/fsharp/pull/13119/commits)

Yeah, you can build it and play around using FSI or compiler itself.

[gsomix]

I suggest to extract abbreviations into another RFC and properly design it to keep scope of current feature narrow. E.g. abbreviations from PR's branch cannot be used to constrain type parameter of class.

Related request from @blumu.

type Printer<^T when 
    ^T : (static member Print : string -> unit) 
and ^T : (static member Flush : unit -> unit)> = ^T

type Combine<^T1, ^T2 when ^T1 :> Printer<^T1> and ^T2 :> Printer<^T2>> = 
  static member inline PrintAndFlushBoth(m: string) = 
    'T1.Print(m) 
    'T2.Print(m) 
    'T1.Flush()
    'T2.Flush()

error FS0698: Invalid constraint: the type used for the constraint is sealed, which means the constraint could only be satisfied by at most one solution

[vzarytovskii]

I think it's fine as it is now. It can go thru another iteration after.

[smoothdeveloper]

@gsomix, the suggestion fsharp/fslang-suggestions#456

[dsyme]

I've added very preliminary guidance on using IWSAMs to the RFC. This is based on the essays in the drawback sections such as this one.

I feel it is necessary to have strong guidance in place in order to justify this feature, and justify our working on it, given it is so problematic. Having the guidance also helps structure discussion and prevent rabbit-holes. It also helps motivate @vzarytovskii and me to work on it 😄

[smoothdeveloper]

Regarding units-of-measure, is it for consideration, that their support could take in account IWSAMs members related to / and * operators (and others, not sure what else is taken in account for those)?

[dsyme]

There's a discussion around about this, will try to find it.

It's a very difficult problem to fix as (unsurprisingly) requires higher kinded types and their use in generic IWSAM definitions like IMultiplyOperators. Without that anything is patch up - eg give warnings when instantiating these with UoM, or make it seem like UoM types don't satisfy these interfaces.

[dsyme]

Here is link to the discussion: dotnet/fsharp#12881 (comment)

Here is a link to why higher kinded types are needed: dotnet/fsharp#12881 (comment)

In brief, today double<m> is considered to implement:

IAdditionOperators<double<m>, double<m>, double<m>>
IMultiplyOperators<double<m>, double<m>, double<m>>

For addition that's fine, and means

    let f (x: #IAdditionOperators<_,_,_>) = x + x

    f 3.0<m>

will return the right thing. However

    let f (x: #IMultuplyOperators<_,_,_>) = x + x

    f 3.0<m>

will return 9.0<m> instead of 9.0<m^2>.

We have four options

1. Don't do anything and accept the unsoundness
2. Give a warning so that each time a unitized type is solves a constraint 'T :> IMultiplyOperators<,,_>` for a specific set of interface types known to have this problem
3. Adjust the F# compiler so that double<m> is considered to implement IMultiplyOperators<double<m>,double<m>,double<m*m> for a specific set of interface types
4. Ask the BCL team to add metadata about the unitization signatures of each of the numeric abstractions.

Likely we will do (3) since it fits with the existing design of F#, where the constraint solver does specific work so that a specific set of SRTP constraints like op_Multiply have their signatures adjust to be correctly unitized.

[dsyme]

I will put this in the RFC

[smoothdeveloper]

Until option 4 is taken (and I count on you to bring the fact that UoM will eventually make it to C#, and will mandate option 4), I like 2 the most, and it would apply to any IWASM (because special casing on some stuff from BCL is like assuming there aren't people doing their own BCL, similarly, there is special casing over Func<> in overload resolution and it doesn't feel great IMO).

Just my .02 cents & thanks a lot for bringing all the details!

[krauthaufen]

There's one other question about ambiguity here when types A and B implement IMultiplyOperators with one another but with a different return type...

The explicit syntax via A.Multiply would resolve that but operators would run into trouble there.

Are you planning to base F#'s operators on IWASM, will they remain SRTP-style and will they accept types implementing IAdditionOperators for example?

Edit:

type A =
    interface IAdditionOperators<A, B, C> with ...

type B =
    Ainterface IAdditionOperators<B, A, D> with ...

Of course the order of parameters would be a natural choice here

[dsyme]

This is TBD. In principle we want IWSAM constrained types to satisfy SRTP constraints but it's not technically easy to arrange. Will keep looking into it.

[dsyme]

Regarding ambiguity - F# won't generally allow multiple generic constraints by the same interface. If it flows from C# we choose the first encountered.

[smoothdeveloper]

Is there a way for client code to overcome ambiguity in such cases? I feel a warning and guidance in it, for being explicit, feels a bit better than "first coming" (which can change, when BCL shuffles stuff).

[krauthaufen]

I think it is actually not ambiguous, since the first type-argument always needs to be the self-type in these implementations.

A needs to implement IAdditionOperators<A,...> so whenever we see A + Bwe need to use A's Implementation (since only this one takes an A as a first argument) while B's implementation has a B in the first place

[krauthaufen]

However I think the implementation of the same interface with different generic instantiations will be crucial for IWASM since matrices and vectors could orherwise not be expressed properly (matrix * vec = vec and matrix *matrix= matrix)

[gusty]

@dsyme
Regarding the simplified SRTP call proposal, would it support or keyword, I mean in the form of ('A or 'B).staticMember?
If so, would it support concrete types, like ('A or MyType).staticMember ?
In the old syntax, there are still limitations for the latter, you get an error FS0010: Unexpected identifier in binding. Expected infix operator or other token. and the only way to make it work is to do some tricks to get type inference unifying it with the concrete type.
In any case a note should be added to the RFC about this.

[vzarytovskii]

It probably shouldn't be part of this feature.

[dsyme]

Yes, this won't be part of this feature.

[dsyme]

@gusty Actually this was like a 2 line change to fix - just in the parser - no internal SyntaxTree or CheckExpression changes needed. It will be in this RFC, it makes sense to do it

[Happypig375]

Can we also deprecate the use of ^T in favor of 'T? Two syntaxes for type arguments are unnecessary.

[smoothdeveloper]

There is an explanation for the distinction:

https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/generics/statically-resolved-type-parameters#remarks

I wouldn't say they are unnecessary, can be helpful to distinguish the two at a glance.

Maybe they you can make a suggestion for review separately?

[vzarytovskii]

Can we also deprecate the use of ^T in favor of 'T? Two syntaxes for type arguments are unnecessary.

Should not be part of this change.

[gusty]

In any case I don't think they should be deprecated. The old style SRTP call drives type inference, sometimes in such a way that's not possible to express in signatures. I don't think the new proposed syntax works the same, from what I saw in the samples is the opposite: type signatures are required.

[dsyme]

The changes in this RFC do go quite close to deprecating ^T. The syntax can still be used, but in general type inference the final staticness will now be determined by the actual constraints present on the type variable, e.g.

let inline f (x: ^T) = x

let g x = f x  // g has type `'T -> 'T` because it gan be generalized as there are no static-only constraints preventing that.

This is necessary: when SRTP constraints are solved by IWSAMs they should not force staticness. So staticness should be emergent from the finalised unsolved constraints.

[dsyme]

I've reviewed my comments about units of measure here: dotnet/fsharp#12881 (comment) and I propose we shift to making a feature restriction here where unitized types are simply not considered to implement System.Numerics.I* interfaces at all.

The current RFC proposes to use rewriting of the interfaces considered to be supported by unitized types, e.g.

Type	Interfaces reported
double	IAdditionOperators<double,double,double>
	IMultiplyOperators<double,double,double>
	etc.
double<m>	IAdditionOperators<double<m>,double<m>,double<m>>
	IMultiplyOperators<double<m>,double<m>,double<m^2>>
	etc.
double<'u>	IAdditionOperators<double<'u>,double<'u>,double<'u>>
	IMultiplyOperators<double<'u>,double<'u>,double<'u^2>>
	etc.

Note the m^2 on the IMultiplyOperators. However, this technique is obviouisly flawed, because it only allows double<m> * double<m> and not, say double<m> * double<kg>, as described in my original comments on the issue. If higher kinded types were supported this would be possible to express but requires a complete revision of the generic math hierarchy.

[ Aside: While this is specific ti UoM, it hints at one reason why I'm not a great fan of the nominal concept modelling being used in System.Numerics.* - concepts are fragile as new genericity requirements are placed on them. ]

Now F# SRTP doesn't have this problem, and it's worth asking why. This is because the F# compiler rewrites each use of the actual target method when resolving an SRTP constraint on a unitized type on a type known to the compiler, so successfully solves a constraint of this form:

static member op_Multiply: double<m> * double<kg> -> double<m * kg>

It's worth considering if this could be done for IWSAM constraints, however I don't believe it can.

1. There is no sensible rewrite - we would need to rewrite the actual op_Multiply signature provided by IMultiplyOperators<_,_,_> but establishing the relationship between the original unitized type and the signature is not possible. We'd need a new internal flag or concept here to establish this relationship
2. There are many interfaces and methods in System.Numerics and they are not necessarily generic enough, e.g. IRootFunction::Sqrt and IRootFunctions::Cbrt have different unitizations. We would need to go through each signature and establish the correct unitization. It could be done but probably shouldn't be baked into the compiler, but rather be a new set of unit-friendly interfaces and metadata in FSharp.Core.
3. The whole thing would be very fragile to additions and changes in the Systems.Numeric methods and hierarchy. We would have to at least wait until the final release of .NET 7

Overall it is better to simply say that unitized types are simply not considered to support the System.Numeric.* interfaces at all. A halfway-house where they support some unit-uniform interfaces like IAdditionOperators<double<m>, double<m>, double<m> doesn't seem worth it, as in practice there will be almost no useful generic math code that is constrained only by T : IAdditionOperators<T,TOther,TReturn>, so what's the point?

At the moment I propose hard-wiring this rule as filtering any interfaces that dervies from anything in the System.Numeric namespace from the list of interfaces reported for unitized types.

[dsyme]

No, I don't think so, certainly not for this particular case - and its exactly the kind of "type-level feature creep" which as you know I have little desire to see. Even if we had it, we would have to have an entire new IWSAM numeric hierarchy in order to make use of it, and do a huge amount of work to simulate its presence on base numeric types.

[gusty]

I see, to me the most reasonable thing to do is to warn the C# team about this, even if they ignore us they might run into this limitation as well.

Question aside, why so much energy fighting back the logical evolution of the language?
HKTs (or better said removing the limitation of only first order kinds) is a natural next step, it will come in the end, maybe in 10 years, otherwise 15 or 20, but I bet it will come, it's just a matter of time.
To me the question is not the "if" but the "when".

[smoothdeveloper]

To prevent this happening, a feature restriction will be used where unitized types are simply not considered to implement System.Numerics.I* interfaces at all.

I am generally not finding hard coding against BCL types a good choice, one example related to System.Func: dotnet/fsharp#11538, dotnet/fsharp#11534.

Trying to find a middle ground as this stop gap measure doesn't solve the problem for IWSAM that are defined elsewhere.

• Would it be better to emit a warning, and put this warning in the "as error" by default on release? it would warn whenever UoM is used as type parameter to an IWSAM used as constraint.
• I assume there is no dichotomy and one can have mixed interfaces (with non abstract static, with non static abstract members), the RFC should precise how the type checker distinguishes IWSAM when it is a mixed interface (in which case the IWSAM members may or may not be exposed to the code, depending if it is used in a generic constraint or just as a type annotation on the signature) and it probably changes considerations for https://github.com/fsharp/fslang-design/blob/main/RFCs/FS-1124-interfaces-with-static-abstract-members.md#warning-when-using-iwsams-as-types

Later, a good language suggestion would come, that enables client code or F# libraries to put annotations on referenced IWSAMs (read: nothing in the compiler nor FSharp.Core) as to how they carry with UoM erased types, and those annotations would clear the warning.

The warning should say that this preview warning is likely to be an error on release, and that a language suggestion is welcome, if this comes to be a real need, it would also provide a pointer to guideline, if SRTP trickery can be used to encode annotations that pleases the compiler by defining the UoM algebra manually and how to transform signature of a particular member, of a particular IWSAM (no idea if this is something that can be hacked with SRTP though).

Also, this makes me wonder if there are implications between IWSAM and erased type generated from Type Providers to consider as well, but there is no algebra related to erased types like there is for UoM, AFAIK.

Question aside, why so much energy fighting back the logical evolution of the language?

This rhetoric worked to get us reified generics, you just need to get hired by Microsoft and commit to work on the JIT and GC the same way @dsyme did, then we'll have HKT in CLR, you can also bring @robkuz in your team to achieve the feat 🙂.

[robkuz]

@smoothdeveloper your words are flattering but I don’t think I am anywhere competent enough to work on a compiler nor is my input wished for and above all - I am already in the process of leaving fsharp.
Good luck with all your wishes

[smoothdeveloper]

@dsyme, outside the HKT digression, have you considered the points about restricting UoM from my comment, I still see a dead angle there, and maybe it is better to leave an escape hatch (warnings that would be errors by default).

I'd like to gather ideas that would allow annotation of relationship required to carry UoM algebra that makes sense and only works due to inline nature of SRTP and cleverness of F# about UoM, but cannot apply to IWSAM.

I believe it would hinge into the type extension, as specialisation, here is a try at it.

[<MeasureAnnotationOnTypeExtension>]
type System.Numerics.IMultiplyOperators<[<Measure>]'TSelf,[<Measure>]'TResult,[<Measure>]'TOther> with
   static abstract member op_CheckedMultiply: 'TSelf<m> * 'TOther<n> -> 'TSelf<m * n>
   static abstract member op_Multiply: 'TSelf<m> * 'TOther<n> -> 'TSelf<m * n>

Maybe this is also useful for other constructs than IWSAM?

[dsyme]

why so much energy...

The rational grounds for avoiding or moderating type-level programming features (HKT, IWSAMs, ML functors, TCs, implicits, refinement types, conditional/structural types ...) is documented both in this RFC and elsewhere. My personal motivation stems from 30 years of seeing repeated obvious misuses of some of these features to create complexity that is, in balance, worse than the problems solved.

This rhetoric worked to get us reified generics

Tbh this is the kind of rhetoric we avoided in order to make our case for .NET Generics. Instead we argued on the grounds of concrete productivity benefits that stood up to scrutiny of those deeply experienced in developer tooling including Hejlsberg, Morrison, Miller, Rudder, Gates and others. Arguing about some inevitable march of history towards the glories of type-level programming would have got us thrown out the door, and indeed many idealistic MSR projects related to optimization or verification regularly failed when they took that approach.

[gusty]

I agree in that HKTs is a feature that can be misused, but that alone is not a reason not to implement a feature, otherwise we won't have all the features we have right now as all of them can be misused. Luckily not everybody made decisions based on "feature x can be misused so let's not do it" otherwise we would be still be programming in plain C, or worst. Plus, I don't think we need a kind of "police of developers", I think the key to have people learning is to teach, not to prohibit.

Also, I don't agree in that HKTs is type level programming, to me is just normal generic types without any restrictions, simply that.
And then of course there are good uses, like LinQ and unit of measures to name a few, of course it's not something you'll see in domain modelling, same way generics as they are now are rare in that area, but in libraries and frameworks it's a different story.

Anyway, I don't want to hijack this discussion, sorry about that, I would say, let's talk again in 20 years :)

[tjwald]

I wanted to ask if the work of the dotnet runtime for abstract statics makes f# want to look at different codegen for SRTP? Will that improve performance? (I have no idea)
@dsyme

[vzarytovskii]

SRTPs codegen is already inlining specific implementation at compile yime, and pretty performant. Abstract statics will involve constrained call/callvirt on a type parameter (which involves some additional work by runtime, if i understand that correctly).

[dsyme]

SRTP calls have essentially zero overhead, except perhaps where the compiler fails to do some obvious reductions that could be fixed.

IWSAMs will have an indirect dispatch except for struct instantiations which will no doubt be inlined and zero overhead.

[edgarfgp]

Would we be able to use Active Patterns with this feature? . I have not seen any mention on the RFC

[vzarytovskii]

Can you show an example of what do you have in mind? How would you use it and how you expect it to work?

[edgarfgp]

For my own education, This is what I was thinking of. Using this feature with AP variations

let (|IsEqual|IsNonEqual|) (x: INumber<'T>) (y: INumber<'T>) =
    match x with
    | x when x = y -> IsEqual
    | _ -> IsNonEqual

[vzarytovskii]

Should not be any surprises there, we should have some tests added.

[krauthaufen]

Hey, i just stumbled on something that might be really a dotnet question, but nonetheless I think it is relevant for F#'s IWASM support:

This feature introduces eomething like "static subtyping", so my question is whether there will be something like a downcast for types.

For example in standard subtyping i can downcast an object to some specific interface when I know it really has the type.

Will something similar be available for static Interfaces? The natural choice would be to "downcast" an instance of System.Type here I think.

[gusty]

I'm trying out F# 7.
The first thing I noticed is that I still can't add a static member to an interface !
I'm not talking about an abstract static member but a normal one.

@dsyme this was added to C# in C# 8.0 and I see no reason why it wasn't added to F# at that time.

Now I thought with this whole new set of features we would catch up, but it seems we're not.

[smoothdeveloper]

@gusty, I believe the RFCs do serve a purpose of language change tracking which is a bit more formal than a suggestion which is accepted, closed and got a PR merged for.

However small the RFC may be ("do like in C#"), it is place where more things get pondered on, and some of the fine details get outlined.

[gusty]

Sure, but I don't think there are such details here. This feature already kind of exists, it's just that we can't write it.
I mean, there's no discussion of how would this interact with that as it's already happening.

I might be overlooking some details, if that's the case or if it's required in anycase I'm happy to write an RFC.

[vzarytovskii]

Yeah, one of the purpose of RFCs is to document any feature(s)/behaviour(s) which diverge from the spec or extend it. So, it's good to have it in the repo.

[gusty]

No problem, I can write one as soon as the suggestion gets approved which I think is normally the workflow.

[gusty]

Suggestion approved, initial RFC proposed here

[gusty]

Still playing with F# 7 and the more I explore the feature the more I realize there are certain omissions in the RFC.
For instance it doesn't mention at all static virtual, whether is it covered or not, or if it should be covered separately (maybe together with normal static members?).

Apart from that, even if there are no adjustments to F# core operators that use SRTP with simulated members, it would be nice to mention it in the RFC as it is a bit surprising to me that eventually an IAdditionOperators doesn't work with standard +.

[vzarytovskii]

static virtual is out of scope deliberately, as are default implementations.
True that compiler won't look for op_* in the interface hierarchy without explicit constraint, I believe this is by design (cc @dsyme):

open System.Numerics

type MyInt(value) =
    member val Value = value
    interface IAdditionOperators<MyInt, MyInt, MyInt> with
        static member op_Addition  (a: MyInt, b: MyInt) : MyInt =
            MyInt(a.Value + b.Value)
    override _.ToString() = $"{nameof(MyInt)}({value})"

let add<'T when IAdditionOperators<'T, 'T, 'T>>(x: 'T) (y: 'T) = x + y
let inline addm(x: 'T) (y: 'T) = x + y

[<EntryPoint>]
let main _ =
    let x = 40
    let y = 20

    let mx = MyInt(40)
    let my = MyInt(20)
    printfn $"{x} + {y} is {add x y}!"
    printfn $"%A{mx} + %A{my} is %A{add mx my}!"
    printfn $"{mx} + {my} is {addm mx my}!" // The type 'MyInt' does not support the operator '+'
    
    0

[dsyme]

I haven't checked but my understanding is the explicit op_Addition on MyInt is needed:

open System.Numerics

type MyInt(value) =
    member val Value = value
    interface IAdditionOperators<MyInt, MyInt, MyInt> with
        static member op_Addition  (a: MyInt, b: MyInt) : MyInt =
            MyInt(a.Value + b.Value)
    static member op_Addition  (a: MyInt, b: MyInt) : MyInt =
        MyInt(a.Value + b.Value)
    override _.ToString() = $"{nameof(MyInt)}({value})"

let add<'T when IAdditionOperators<'T, 'T, 'T>>(x: 'T) (y: 'T) = x + y
let inline addm(x: 'T) (y: 'T) = x + y

[<EntryPoint>]
let main _ =
    let x = 40
    let y = 20

    let mx = MyInt(40)
    let my = MyInt(20)
    printfn $"{x} + {y} is {add x y}!"
    printfn $"%A{mx} + %A{my} is %A{add mx my}!"
    printfn $"{mx} + {my} is {addm mx my}!" 
    
    0

It would be expected that this is defined for any standard .NET numeric type.

[ShalokShalom]

Opening the can of cans of discussions.

Suggestion: fsharp/fslang-suggestions#1151 RFC: https://github.com/fsharp/fslang-design/blob/main/RFCs/FS-1124-interfaces-with-static-abstract-members.md

Hi 😊

The link to the RFC changed, if you wanna update it: https://github.com/fsharp/fslang-design/blob/main/FSharp-7.0/FS-1124-interfaces-with-static-abstract-members.md

[smoothdeveloper]

Thanks, updated!