Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

So I think I know the main use case for F# 3.0's Type Providers, i. e. better Intellisense when working with data stores that use them. Are there other use cases for Type Providers or is that pretty much it?

share|improve this question
    
As written, this is a list-style question which would be off-topic. Would you provide some more details around your question so we can provide a better answer for you? –  GlenH7 Oct 25 '12 at 14:30
    
@GlenH7 Fair criticism but I couldn't think of any other way to phrase this. Close it if you want; I'll ask on the F# mailing lists. Just thought others might want to know this as well. –  Onorio Catenacci Oct 25 '12 at 14:39
1  
I suspect that the list of possible uses is constrained enough that the question is answerable. If the idea of a laundry list bothers you, specify a category of uses in your answer. –  Robert Harvey Oct 25 '12 at 14:44
2  
Maybe it would be better if phrased as "What is the main usecase for F# 3.0's Type Providers, aside from better Intellisense" or maybe "Aside from aiding the IDE, what is the main purpose in adding Type Providers to F# 3.0"? Of course, I don't actually work with F# so it's also possible these variations of the question don't even make sense. ;) –  FrustratedWithFormsDesigner Oct 25 '12 at 14:56
1  
They're used primarily for accessing diverse data sources, such as databases and web services. See msdn.microsoft.com/en-us/library/hh156509.aspx –  Robert Harvey Oct 25 '12 at 15:06

2 Answers 2

up vote 4 down vote accepted

I think you'll find that there is really only 1 use case for F# Type Providers - that is, getting strongly typed data from data sources.

What I think you might be asking is what good is getting that kind of type information? Well, as you mentioned, it allows you to use intellisense better, but I think that's actually a side effect or more of a happy coincidence.

I think you'll find that the benefits of having strongly typed data available are inline with the benefits of having a strongly typed language to begin with.

Interestingly, if you take a look at the page that has (what I believe to be) the original spec/proposal/design document for type providers, you'll find:

Providing strongly typed access to these sources is a key consideration for strongly-typed programming languages, to insure low impedance mismatch in information access. At this scale, [current methods] are manual, clumsy, and do not handle the internet-scale information sources...

(emphasis and edits mine)

share|improve this answer
    
Thanks @SnOrfus--answers my question quite well. –  Onorio Catenacci Oct 25 '12 at 16:41

There are F# Type Providers for things other than what is traditionally thought of as data.

One example is the FunScript type provider:

FunScript is a lightweight F# library that lets you rapidly develop single-page applications. You can connect to external data sources and call REST APIs with intellisense, produce dashboards using JavaScript visualization libraries and write asynchronous computations easily without explicit callbacks.

Another one is the F# R type provider:

An F# type provider for interoperating with R.

So you can see that type providers can be used to provide interoperability to other programming languages (JavaScript and R shown here).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.