Back to Questions
1.5k
views5
comments
Curried methods and .NET-compatible types
f#compiler

Hi,

I have recently been bitten by a "side-effect" of F# and .NET interoperability. I am designing a Vec3d class which looks as follows:

1
2
3
4
5
6
7
8
9
10

type Vec3d = struct
    val x: float
    val y: float
    val z: float
    
    new (x, y, z) = { x = x; y = y; z = z }
    
    static member plus (a: Vec3d) (b: Vec3d) = Vec3d(a.x + b.x, a.y + b.y, a.z + b.z)
    static member scale (k: float) (a: Vec3d) = Vec3d(k * a.x, k * a.y, k * a.z)
end

Now, about my problem: If I look at the generated code for 'plus' and 'scale' shown as C#, I get:

1
2

    public static FastFunc plus(Program009.Vec3d a);
    public static FastFunc scale(double k);

This means that all calls to 'plus' and 'scale' will always result in instantiating new objects (the returned FastFuncs), which results in significant slow-downs.
Suggestion:
I think the compiler should emit warnings when encountering curried methods in .NET types for the following reasons:
1) If the intent is to design a type accessible to other .NET languages, curried methods should be avoided as the caller probably won't know what to do with the returned FastFunc.
2) If the intent is not to design a .NET type, the method is unexpectedly slow compared to other curried F# functions. Indeed, non-partial evaluations of non-class curried functions are optimized to use the usual calling convention.

Question:
Is there a way to tell the F# compiler that certain types are not meant to be usable from .NET, allowing the compiler to perform optimizations it does in the rest of the code?

.

Hi,

There are some interesting subtleties around functions that are members of classes, if you have curried function it appears as FastFunc to C#, if you have used the tuple syntax it appears as normal method to C#, see the difference here:

1
2
3

    static member plus ((a: Vec3d), (b: Vec3d)) = Vec3d(a.x + b.x, a.y + b.y, a.z + b.z)

    static member scale (k: float) (a: Vec3d) = Vec3d(k * a.x, k * a.y, k * a.z)

I agree this is a little strange as if you made the functions via let bindings, both the functions would look the same to a C# client:

1
2
3

let plus ((a: Vec3d), (b: Vec3d)) = Vec3d(a.x + b.x, a.y + b.y, a.z + b.z)

let scale (k: float) (a: Vec3d) = Vec3d(k * a.x, k * a.y, k * a.z)

There are currently two ways to hide type definitions from external programs using an mfi file or using the "internal" keyword:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

type internal Vec3d = struct

    val x: float

    val y: float

    val z: float

    

    new (x, y, z) = { x = x; y = y; z = z }

    

    static member plus (a: Vec3d) (b: Vec3d) = Vec3d(a.x + b.x, a.y + b.y, a.z + b.z)

    static member scale (k: float) (a: Vec3d) = Vec3d(k * a.x, k * a.y, k * a.z)

end

Cheers,

Rob

By on 10/13/2008 3:46 AM ()

Thanks for the info.

It seems however that declaring the methods 'internal' does not help, performance-wise. Their signature remains the same, i.e. they take one argument and return a FastFunc.

By on 10/13/2008 11:08 AM ()

Have you tried turning up the optimization level, the -o compiler switch? This will mean that more methods are inlined. Alteratively you can use the "inline" keyword, but I believe this only works with let bindings and not object methods.

Cheers,
Rob

By on 10/13/2008 12:39 PM ()

I have optimization enabled in the project properties (I'm using Visua lStudio). Are there several levels of optimization?

Actually, I'm fine with avoiding curried methods, so it's not really a problem.

By on 10/15/2008 11:40 AM ()

We are indeed looking at normalizing the compiled/C# view of curried members to align with the compiled/C# of curried functions defined in modules.

For now, curried members should not be used in APIs for use from other .NET languages.

Thanks for the feedback!

Don

By on 10/15/2008 2:20 PM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper