If you wanted a low-tech solution, you could rely on mutable function values and expose those. For example:

1
2
3
4
5
6
7
8
9
10
11
#light

type Foo() =
    let mutable m_plotFunc : (int -> int -> unit) option = None

    // Calls Foo.Plot
    member this.Plot (x, y) = 
        match m_plotFunc with
        | Some (f) -> f x y
        | None -> failwith "Plot function not set!"    // Sets the plot function
    member this.SetPlotFunction f = m_plotFunc <- Some(f)
By on 9/5/2008 2:18 PM ()

Very interesting - thanks. I think a F# interface to Matlab could be pretty useful. Maybe at some point I'll create a script to generate F# method stubs for all the Matlab toolboxes (hopefully even including some intellisense help). It's a shame this can't be done on-the-fly using some runtime metaprogramming, though.

By on 9/7/2008 12:48 PM ()

Hi,
as Kurt said, you cannot add new members to the object dynamically. However, I think that creating library like the one you mentioned is very well possible in F# - even though it isn't easy task. I agree that writing all the functions explicitly like this would be a bit tedious:

1
2
 
let plot x = convertresult(mlab.evaluate("plot", convertargument(x)))

You can avoid this in F#, but as I said, it is a bit tricky. You could just define abstract types (interfaces) that describe what methods do the objects returned from Matlab have (probably just "r.[...]" accessor) and declare an abstract type with function signatures:

1
2
3
4
5
6
7
8
9
10
11
12
13
 
// Annotates interfaces that are just wrappers for matlab functions
type MatlabTypeAttribute() =
  inherit System.Attribute();;

// Represents the matlab matrix type 
[<MatlabType>] type Matrix = 
   ...;;

// Represents the library with matlab functions
[<MatlabType>]
type Mlab =
   abstract plot : Matrix -> unit;;

The benfit is that you write all the signatures, so everything is statically type checked (you won't get runtime error) and you can also provide documentation for each member (that will be displayed in the visual studio). Since you'd write just abstract members, it's also not too much writing.

The tricky part would be to write a function that returns the implementation of the interface. You would use it like this:

1
2
 
let mlab = GetMatlabImplementation<Mlab>()

The function would be quite dynamic - it could use System.Reflection & System.Reflection.Emit namespaces (or maybe CodeDom, which is slower, but easier to use) to generate and return the implementation of the interface that contais all the indirect calls and conversions.

I implemented the same thing for PHP here: [link:tomasp.net]
and you can also find good ideas in this article: [link:www.codeproject.com]

T.

By on 9/5/2008 3:33 AM ()

Hi Aatreya,

F# is a statically typed language (unlike Python), which means that if you're calling mlab.plot on some static class mlab, or an object named mlab, F# statically enforces that this method plot exists. If you can't be sure that this method exists at compile time, you have to resort to some sort of reflection as you point out.

However, it would seem to me that if you're writing a wrapper for matlab, defining functions like mlab.plot would be the whole point of your library, so I'm afraid I don't see the problem here. The python implementation needs to do that as well, the only difference is you'll get a runtime error in python, while for F# the compiler will complain before running your program.

cheers,

Kurt

By on 9/5/2008 1:36 AM ()
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