Back to Questions
1.1k
views9
comments
Syntax for constraining type based on member function existance?
f#

Suppose I want to write a function f that can take any type 'a with a Parse method that has the signature of which is 'b -> 'a. The function f would have the type 'b -> 'a as well. What would be the correct syntax to do this. So for example, I want a function called Parse2 such that the following works:

let x:int = Parse2 "7"
let y:int64 = Parse2 "4328032"
let z:DateTime = Parse2 "4/31/1998"

But the following does not:

let w:string = Parse2 "fail"

The implementation of Parse2 should look basically like this:

let fun Parse2 x =
'a.Parse(x)

Is this possible?

.

Hi,
it can be done, but there are restrictions. This is really not something that could be represented by the .NET at runtime, which means that the compiler has to process this only during compilation (just like C++ templates). However, you can write this:

1
2

let inline parse< ^a when ^a : (static member Parse : string -> ^a) > (s:string) : ^a =
  (^a : (static member Parse : string -> ^a) (s))

The keyword "inline" is required, so that the compiler knows that the function should be inlined and the "^a" type parameter is instantiated.

T.

By on 11/21/2008 4:38 PM ()

Hi,
the compiler has to process this only during compilation (just like C++ templates).

Perfect! I'm a C++ programmer at heart, and having used C# Generics a bit I've always felt terribly limited by this aspect of C# generics. This makes me love F# even more. I have a question though. Let's say now that this member is not static, but instead requires an instance. A good example is the StreamWriter.Write() method. Ideally I would like to be able to write code such as:

1
2
3
4

let writer = new StreamWriter(new FileStream("test.txt", IO.FileMode.Create))
Write2 writer 4
Write2 writer "test"
Write2 writer 'a'

Of course I would like this code to be able to work not only with StreamWriters, but with any class that has a method called Write that takes one argument. I have tried something like the following:

1
2

let inline Write2< ^a when ^a : (member Write : 'b -> unit) > (w:^a) (s:'b) : unit = 
    (w : (member Write : 'b -> unit) (s))

but this does not work. I have to wonder though. This seems really complex when in theory it seems like it should be easy (like it is in C++). Even in the first example (the static case), is there some technical compiler limitation preventing me from writing the much more obvious syntax

1
2

let inline parse< ^a when ^a : (static member Parse : string -> ^a) > (s:string) : ^a =
  (^a.Parse(s))

and in the second case

1
2
3
4

let inline Write2< ^a when ^a : (member Write : 'b -> unit) > (w:^a) (s:'b) : unit = 


    (w.Write(s))
By on 11/21/2008 5:04 PM ()

Of course I would like this code to be able to work not only with StreamWriters, but with any class that has a method called Write that takes one argument. I have tried something like the following:

1
2

let inline Write2< ^a when ^a : (member Write : 'b -> unit) > (w:^a) (s:'b) : unit = 
    (w : (member Write : 'b -> unit) (s))

but this does not work.

Have you seen this page? It shows how to do what you want for a non-static member taking no argument. I have made multiple attempts to guess what the syntax would be for a non-static member taking arguments, but without success so far.
I have also managed to crash the compiler (bug reported and registered) when playing with constraints, and I am therefore staying clear of them for the moment.
I find the alternative shown by tomasp to be more elegant, and more general as well. What if the users of your generic code are not using classes, or what if their write methods are called something else, e.g. writeToFile?

By on 11/22/2008 2:58 AM ()

Have you seen this page? It shows how to do what you want for a non-static member taking no argument. I have made multiple attempts to guess what the syntax would be for a non-static member taking arguments, but without success so far.

Ok, I got it to work with one argument:

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

type duck() = 
    member x.speak() = "hi!"
    member x.talk() = "hello!"
    member x.repeat(s:string) = s
    
let inline speak (a: ^a) =
    let x = (^a : (member speak: unit -> string) (a))
    printfn "It said: %s" x
    let y = (^a : (member talk: unit -> string) (a))
    printfn "Then it said %s" y
    let z = (^a : (member repeat: string -> string) (a, "whassup"))
    printfn "Then it repeated %s" z

Thanks for the link, hadn't seen it!

Edit: I still can't get it to work if the methods are overloaded on signature though. E.g. there is another member x.repeat(n:int) = n. Whichever call comes first is the one that is used throughout the rest of the function. e.g. if you try to call it with an int first, calling it with a string later is invalid, even if you use the correct constraint syntax. Oh well, not a big deal, just a curiosity.

By on 11/22/2008 6:08 AM ()

What if the users of your generic code are not using classes, or what if their write methods are called something else, e.g. writeToFile?

Well, it would need to be restricted to code internal to a particular library, and not accessible to anyone but me. Perhaps part of the problem is that I'm still "thinking in C++". In C++ pretty much all of STL and boost are built on this concept using templates, which is the reason that they are as powerful as they are. Of course you don't -need- any of these concepts to achieve genericity in F# or any functional language, since obviously polymorphic compile time construct can easily be converted into an equivalent runtime polymorphic construct. Like tomasp mentioned in a previous post, we can just pass a lambda function to make the write call. But still, I can't help but think the technique might eventually be useful, even if only as a micro-optimization to remove one function call.

Plus I always try to learn the esoteric and difficult features of a language first :)

By on 11/22/2008 6:01 AM ()

What if the users of your generic code are not using classes, or what if their write methods are called something else, e.g. writeToFile?

Well, it would need to be restricted to code internal to a particular library, and not accessible to anyone but me. Perhaps part of the problem is that I'm still "thinking in C++". In C++ pretty much all of STL and boost are built on this concept using templates, which is the reason that they are as powerful as they are. Of course you don't -need- any of these concepts to achieve genericity in F# or any functional language, since obviously polymorphic compile time construct can easily be converted into an equivalent runtime polymorphic construct. Like tomasp mentioned in a previous post, we can just pass a lambda function to make the write call. But still, I can't help but think the technique might eventually be useful, even if only as a micro-optimization to remove one function call.

Plus I always try to learn the esoteric and difficult features of a language first :)

Actually, I have been there :) I'm also coming from the C++ world, and templates have always fascinated me. One thing you might have missed is that all it takes to have compile-time polymorphism in F# (with its speed benefits and its code size blowup disadvantages) is to declare generic functions as inline.

I hope I am not saying anything incorrect if I say that in F#, the "inline" keyword differs from C and C++. In these languages, "inline" is just a hint that compilers may ignore. In F#, "inline" function definitions will always cause the compiler to generate code at call sites. See what happens when you define a recursive inline function (you get an error). Disclaimer: That information is based on my personal experiments, I haven't found in the F# manual what "inline" exactly means.

By on 11/22/2008 7:57 AM ()

What I'd really like is some macro system in F#. Something that would give us an AST, then allow us to return an AST, at compile time.

I've not used member constraints _that_ often. But, when I do, they're always very useful, and allow me to refactor code I otherwise would not be able to. (Say, I have 10 different object sequences, and I want to pull out the name in each one. It just so happens that all of them have the name "Name", so an inline expansion is much nicer than having to provide a textually-equivalent lambda (fun x -> x.Name) )

Anyways, I'd think a macro system would be even more useful. Also, it'd probably be difficult enough that perhaps it would not be abused like textual macros are.

By on 11/22/2008 6:22 PM ()

Ah, sorry for the confusion.
It really works even for non-static members. I thought that's not possible! (but still, I'd say that this is a feature that should be used carefuly, but I can see many useful applications...)

T.

By on 11/22/2008 4:03 AM ()

Hi,
I think this is more a philosphical question. Technically, I guess it could be possible to allow this, howeve this feature is quite limited in F# (you have to use inlining) and is really intended mostly for numerical code where you want to use same functions for various numeric types.

I think that F# usually has different ways for achieving things like this. Your "write2" can for example take a writing function as an argument:

1
2
3
4
5
6
7

> let write2 (f:'a -> unit) (v:'a) = f v;;
val write2 : ('a -> unit) -> 'a -> unit

> "Hello" |> write2 writer.WriteLine;; 
// Note, if we write "Hello" on the left using pipelining, 
// the F# compiler will be able to resolve the overloaded "WriteLine" method
val it : unit = ()

BTW: I used C++/CLI a bit and I thought that the combination of generics and templates is really powerful, however it is really mind-blowing, so I guess it is better to keep the language (relatively) simple, but I agree that this is a limitation - I'm just not sure whether templates like those in C++ would make F# code better... At least there is some area where the F# team can do improvements once the version first version is officially relesed :-)!

By on 11/21/2008 5:37 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