CODEWITHSUNDEEP
c#.netf#type-providers
carstenj
carstenj

Reputation: 703

Could F# type providers be incorporated in C#

The cool new F# 3.0 feature type providers can be used to bridge the mismatch between F# data types or classes and data source structures like XML or WSDL. However this mismatch is also a challenge in other .NET languages like C#.

I'd like to use the F# 3.0 providers in C# code. How can I do this, if at all? Further, if we cannot, what would a C# implementation need to be able to use them?

Upvotes: 42

Views: 6713

Answers (2)

Tomas Petricek
Tomas Petricek

Reputation: 243041

I think @kvb gives a good overview of some of the technical difficulties. I agree type inference would be problematic - you would be basically limited to using provider generated types locally, similarly to anonymous types. I think C# might come with something similar in Roslyn, but I doubt it will be as elegantly and smoothly integrated as in F# (where type providers are actually language feature and not just tool).

To answer your two specific questions:

[How can I] use the F# 3.0 providers in C# code?

The F# type providers are really only understood by F# compiler, so you'll need to use them from F#. For generative type providers (SQL, Entities, WSDL, config files), you can reference the provider from F# and use the generated types from C# projects.

For erasing type providers you won't be able to do this, because the types do not really exist and only F# can see them. So the best option is to write your processing code in F# and return results as collections of records or other types that are easily consumed from C#.

What would a C# implementation need to be able to use them?

I could, of course, just say "C# would have to support type providers!", but here are some more thoughts. Type providers are just .NET assemblies and they do not use any F#-specific types. The ITypeProvider interface could be consumed by any .NET language including C#, so if C# designers wanted, they could reuse all the great providers already built for F#.

So, submit this suggestion to the C# user voice or advocate it elsewhere (or convince the Mono team to implement this!) and perhaps it will be added in C# (vNext + 1 + ...). For now, you'll only get all the benefits in F#.

Upvotes: 29

kvb
kvb

Reputation: 55184

Some aspects of how type providers work are particularly tailored to the needs of F# programmers, but may be less compelling when considering solutions to strongly-typed data access for other languages. For instance, a lot of F# programming is done in F# Interactive, and type providers enable this workflow very nicely compared to code generators (which require a language-external mechanism for generating source code files). Since C# programmers are used to slower edit-compile-run cycles, this may be less important in a C# setting.

From a technical perspective, I suspect that F#'s more pervasive type inference is probably the biggest advantage compared to languages like C#. For instance, if I want to wrap some data access logic from a type provider in another type, I can do something like this:

let moviesStartingWith prefix =
    query {
        for movie in MyDataSource.Movies do
        where (movie.Title.StartsWith(prefix) }
    |> Seq.toList

In C#, I'd need to specify the return type (e.g. List<DataSource.ServiceTypes.Movie>) which ends up being a chore, and which means that even with IntelliSense, I'm dotting through the set of provided types to generate the signature in addition to dotting through the set of provided values to generate the query.

This applies to areas other than type providers, too, of course, but I think that with some of the nested type hierarchies that are naturally generated by some of the providers this would be especially painful in practice because the type names become extremely long.

Upvotes: 9

Related Questions