Tips on designing a .NET API for future use with F#

I'm in the process of designing a .NET API to allow developers to create RoboCup agents for the 3D simulated soccer league.

I'm pretty happy with how the API work with C# code, however I would like to use this project to improve my F# skill (which is curr开发者_开发技巧ently based on reading rather than practice).

So I would like to ask what kinds of things I should consider when designing an API that is to be consumed by both C# and F# code.

Some points.

• I make fairly heavy use of matrix and vector math. These are currently immutable classes/structs.
• The API currently defines a few interfaces with the consumer implements (eg: IAgent), using instances of their implementations (eg: MyAgent) to construct other API classes (eg: new Client(myAgent)).
• The API fires events.
• The API exposes a few delegate types.
• The API includes several enums.

I'd like to release a version of the API as soon as possible and don't want to make major changes to it later if I realise it's too difficult to work with from F#. Any advice is appreciated.

---

The best advice is probably to try using the API from F#. :)

That said, I think what you have sounds fine

• any good C# API should be a pretty good F# API
• there's a little friction when using delegates/Func/Action at the boundary, but there's nothing you would change here
• enums, events, interfaces, classes, structs are all fine
• if possible, do avoid APIs that return values that are typically ignored (e.g. fluent interfaces that 'return this' to be able to 'chain calls' - these cause F# to need lots of |>ignores)

But really, take an hour and try writing an F# consumer of the library. In all likelihood, in the worst case, you might suggest a few helper functions or extension methods for F# to smooth over any friction points at the interface boundary, but I think what you have should all just be fine.