Hello.

I did not know that objects can have polymorphic, or generic methods.
I was lucky to stumble across this post; is it written in the manual?

However I could not manage to implement the following interface:

1
2
3
4
5
6
7
8
9
10
11
12

type 'a c_map = interface
  abstract map<'b> : ('a -> 'b) -> 'b c_map
end;;


type 'a c_list(init: 'a list) = class
 interface 'a c_map with 
 member self.map f = (new (_ c_list) (List.map f init) :> _ c_map) end
end;;

//stdin(6,13): error: The member 'map: (('a -> 'a) -> 'a c_map)' did not have the correct number of type parameters.  
//The required signature is 'abstract member c_map.map : ('a -> 'b) -> 'b c_map'.

I tried some variations in vain.
Could you give me some help please?

By the way, the following code

1
2
3

type 'a c_map1 = interface
  abstract map<'b> : (('a -> 'b) -> 'b c_map1)
end;;

gives rise to an error "forceM: envGetMethB: failed ....".
It would be nice if the message is more helpful;
I do not understand what was wrong :-(

It is likely that you are aware of this, but here is my related thought.
That both records and objects support polymorphic methods has more significance
in OCaml. Since objects are structural, there are limitations on the possible
polymorphic methods that object can have. This would not be the case in F#.

With best regards,
Keiko

Because interfaces satisfy this requirement we're contemplating seprecating support for first-class generic record fields. I'd appreciate your thoughts on this.

Hi Don,

Thanks! I feel fine with the solution you proposed.

On the other hand, I'm not qualified enough to comment on the languge choice of F# since I'm actually new to the dotNet platform, but here are some related thoughts on OCaml. It's well known that records, objects and modules of OCaml have a large overlapping on functionality. Even worse, sometimes we choose one of them as the underlying implementation not because it's the most suitable one but because the most suitable one doesn't have a single specific features we need. For example, sometimes we use ocaml objects simply because we want our records extensible. I would hope F# to make one of them expressive and flexible enough to suppress the other two (or keep them in a minimal-complexity form). Of course, that's not easy, since you want a feature both expressive/flexible and lightweight (for most default cases, on both syntax and running cost), but if I design a new language from scratch this would be one fo the considerations.