Back to Questions
2.3k
views4
comments
instance methods as functions
f#compiler

I have often wanted to write code which pretended that instance methods/properties were really static functions whose first argument was the instance on which they should operate, i.e. as if one could write "hello".Length as string.Length "hello". In this form, it's not terribly compelling, but as a function value, it makes for less syntatic noise

1
2
3
4
5

// nice enough
["a"; "bc"; "def"] |> map (fun a -> a.Length)  // = [1; 2; 3]

// nicer
["a", "bc", "def"] |> map string.Length  // = [1; 2; 3]

The semantic that seems sensible to me is that all instance methods in a class are exposed as static methods which can be curried, that is you'd define all instance methods as being of type (f: obj -> (args, possibly tupled) -> return_value) instead of

1
2
3
4
5
6
7
8
9
10

// imaginary, abridged representation of System.String
type string = class
    member this.Length = (* *)
end

// would automagically bcome
type string = class
    member this.Length index = (* *)
    static member Length this = (* *) // this method automatically created
end

Another representation would be to curry in the other direction (f: (args, possibly tupled) -> obj -> return_value), so that you could do something like

1

["that"; "this"] |> map (string.Substring 1) // = ["hat"; "his"]

Since .NET doesn't allow static and instance methods to have identical names, it seems this transformation would not result in any ambiguity. I can imagine some complications in compilation, as IL has different opcodes for static and instance method dispatch, but a compiler could presumably figure out when to use what.

Whether to rewrite as obj -> args -> result or args -> obj -> result is not obvious to me, so perhaps this is reason enough to force users to be explicit. Nonetheless, I have found myself wanting to do the latter (args -> obj -> result) many many times and thought I'd ask.

.

Hi,
I quite like this idea, because I think it would be helpful very often.
I think that the other possible way to realise this in the language would be to allow something like:

1
2

 
["that"; "this"] |> map (_.Substring 1)

However this would be probably quite a big change, because it could be used more generaly:

1
2
3
4
5
6
7
8

 
// Fixes length of the substring, leaves instance and start index as an arguments
// The singature of f would be: string -> int -> string
// Note: We need type annotations here
let f = ((_:string).Substring _ 1) 

// Use getIndex to get the second argument, leave the first argument as function argument
["that"; "this"] |> map (f _ (getIndex()))

I think it would be probably quite difficult to implement and it changes the language more than we may want (and also it uses "_" for other purpose than how it is used currently, which could be a problem), but it could be useful in some situations.

By on 6/14/2007 4:03 AM ()

I think this might lead to more ambiguity than necessary. Actually generating classes with extra static members (as I suggested before) also seems too overeager (and not necessarily what other CLR consumers would expect). On reflection, I think this would simply be an F# feature. The effect might be that during compilation, a class containing

1
2

member this.F x = (*  *)

would be augmented with

1
2
3
4

[{NonEmittedCode}]

static member F x this = this.F x

where [{NonEmittedCode}] is a magic lump that talks the compiler into doing just that. Is it a macro? I'm not sure.

There aren't really any macros in F#, right?

(forgive the curly braces above where angle brackets are correct. I can't convince the editor to accept brackets or <)

By on 6/14/2007 4:06 PM ()

... which reminds me to ask ... why is the suggested idiom for class members to use "x" instead of "this"?

1
2

member this.f x = (* *)

That the name can be arbitrary fits in with the spirit of function definitions elsewhere in the language, but in the spirit of making the association with object-oriented practices explicit, why not encourage the use of "this" or "self"? (Now, objecting to "Me" just out of a sense of taste is entirely acceptable to me.)

By on 6/14/2007 7:14 PM ()

Hi guys,

Another suggestion is to use "#Property" to turn a property into a first class method, with the object type being inferred from context. The same would be applied to instance methods, probably using the curried translation sugested above, and again relying on type inference to sort things out.

Re this/self/x - it's up to you - there's no hard-and-fast guideline in this area. Personally I don't like self/this because they they describe its scoping, not what the object really is. It's like calling a variable "var", arguments "arg1, arg2" and a global variable "global". :-)

don

By on 6/17/2007 4:23 AM ()

    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