Two ways in which member functions aren't quite 'real' functions. I'm looking for an understanding of how, or why not, F# can make these act more like I would hope.

First, Imagine I want to define a member function which is memoized.

1
2
3
4
5

#light
let memoize f = (fun x -> f x) // just pretend
type Foo = { x:int } with
  member this.More n = this.x + n
  member this.EvenMore = memoize (fun n -> this.x + n)

Works fine. I can call it from F# all day long:

1
2

{x=5}.More 3 // 8
{x=5}.EvenMore 3 // 8

However from C#, things are different. More is a member function like you'd expect. But EvenMore is a property of type FastFunc<int,int>. Well that sort of makes sense, it's what we wrote after all.

But it is a shame that to achieve what I would argue is the "expected" result in C#, we would have to wrapper the call ourselves. I understand that F# closures are implemented as FastFuncs instead of delegates for a reason, but I feel like the above definition should let a C# consumer call EvenMore as a straight-up .NET member function.

Second, member functions are also not available as first class values. Why must I say

1

[ 1;2;3 ] |> Seq.map (fun n -> n.ToString());;

instead of

1
2
3

[ 1;2;3 ] |> Seq.map Int32.ToString

Now I suppose this is like a mirror of the above question. Why isn't the system supplied 'member unit -> string' able to masquerade as a plain old F# '(int-> string)'? One answer might be that Int32.ToString is a MethodGroup, not a function, and that I'd have to potentially disambiguate overloads if they existed. (F# does already let me use the static method Int32.Parse this way.)

Typing these questions has revealed the deeper question I think I was after. Why can't .NET class member functions be more like pure F# functions, or why can't I more often just pretend that they are?