F# type providers

F# 3.0 has a new feature called Type Providers:

An F# type provider is a component that provides types, properties, and methods for use in your program. Type providers are a significant part of F# 3.0 support for information-rich programming. The key to information-rich programming is to eliminate barriers to working with diverse information sources found on the Internet and in modern enterprise environments. One significant barrier to including a source of information into a program is the need to represent that information as types, properties, and methods for use in a programming language environment. Writing these types manually is very time-consuming and difficult to maintain. A common alternative is to use a code generator which adds files to your project; however, the conventional types of code generation do not integrate well into exploratory modes of programming supported by F# because the generated code must be replaced each time a service reference is adjusted.

This feature opens the door to some interesting applications, see for example the generation of vector types.

Closely related

The language Magpie builds its entire type system around this concept. All its types are implemented as type providers. This kind of programmable type system could be the future of types. It would be interesting to see what kind of types can be implemented on top of this, and how it can be extended to support the types that cannot currently be implemented on top of this.

By Jules Jacobs at Wed, 2011-10-05 08:33 | login or register to post comments

Can't wait...

...to play with it, I just hope it is fully at compile-time and it can work under .Net CE (for the XBox)!

By giuseppemag at Sun, 2011-10-09 16:29 | login or register to post comments

I would guess because

I would guess because Intellisense works its not dynamic, but then again I wasn't sure that F# worked very well on the 360 or WP with the archaic garbage collector of the compact CLR.

One thing to consider: lots of websites use JSON which means a static format might not be well defined (e.g., they might use unions).

By Sean McDirmid at Sun, 2011-10-09 23:31 | login or register to post comments

IIUC, typ providers...

...make Intellisense dynamic en passant, since they let you run arbitrary code to do type resolution,

Don showed a mind-blowing demo where he wrote a type provider that connected to www.programmableweb.com, and then Intellisense searched thousands of web APIs on the fly as he wrote a mashup.

He mentioned that it was easiest to automate WSDL APIs than JSON ones. This was not because of unions (XML schemas already allow unions), but because WSDL's metadata (which humans usually find bureaucratic and annoying) made it easy to compute type schemes for Intellisense.

By neelk at Mon, 2011-10-10 06:53 | login or register to post comments

Thanks for the

Thanks for the clarification. I wasn't sure if the meta-programming was happening statically or on demand. I agree type providers are very cool! I can't wait until we get this in C#.

JSON can have data-dependent unions and such, I'm guessing WSDL is similar? The primary problem with JSON is the lack of a schema at all, that structure is merely documented and often not very disciplined. An explicit schema might force better design, beyond providing something to process.

Unfortunately, JSON is dominating right now, perhaps because of their low barriers (crappier designs are easier to do) and the popularity of Javascript.

By Sean McDirmid at Tue, 2011-10-11 00:00 | login or register to post comments

I think JSON is dominating...

...because it's a much better format. It's not perfect, but it's still good. It lets you serialize common data structures easily and readably without any hassles.

The XML web services stuff (WS-*) is really appallingly badly designed. The fact that F# can get metadata out of it is basically the silver lining to a very dark and miserable cloud.

By neelk at Tue, 2011-10-11 06:39 | login or register to post comments

I asked Don about handling trillions of web "types"

He said that his solution is to just use type erasure.

Are there better ways to handle more types than we can fit in memory (RDF/OWL), or is type erasure it?

By Z-Bo at Tue, 2011-10-11 21:06 | login or register to post comments

you don't have to

F# 3.0 comes with the publicly available Visual Studio 11 developer's preview if anyone wants to try making their own type providers.

By kclancy at Mon, 2011-10-10 23:43 | login or register to post comments

First impressions

Ok, I read through the Vector example and then washed out my eyeballs with isopropyl alcohol. Am I right in seeing a host of convoluted interfaces, oodles of "properties" and - GASP - most blech-worthy, strings intended as code to be compiled at some point or another by yet another Microsoft monolithic "framework."

IDE Intellisense shmushed in with a language feature? Puleeze... As a wee tike, I was accused of "writing Pascal in C" by my betters. Maybe someday, Microsoft will allow mediocre programmers to "write VB" inappropriately in any language.

Is Microsoft uniquely capable of turning any elegant language into something with absolutely none of the elegance of even good old fashioned macros, but with all the misery of COM (and more API's in misguided attempts to make it palatable), or of some "fill in the blanks" wizard, or worse, of one of the oodles of deprecated or abandoned half-assed "api's" or "frameworks" (Remember Net DDE? Or how many different MS api's are there now to just access a crappy old RDBMS - when SQL was originally conceived back in the '70s as a simple query language suitable for secretaries to use?)

All I see here is more Microsoft style boiler-plate-maximus style "programming" for dummies. A simple ANSI C compiler looks delightfully elegant by comparison.

Again, just first impressions. Maybe I'm just an "old-timer."

- Scott

By scottmcl at Mon, 2011-10-10 04:11 | login or register to post comments

Usability is key, most

Usability is key, most developers like tooling. The primary advantage of type providers is that they pump static semantic feedback back to the developer, so you get nice compiler errors and Intellisense works. If these features aren't interesting to you, then this work won't be interesting to you either.

Its not just Microsoft. Any company who caters to a large developer population panders to usability issues (IBM, Apple, even Google).

By Sean McDirmid at Mon, 2011-10-10 05:36 | login or register to post comments

Intellisense comes virtually

Intellisense comes virtually for free if you have the compiler going off and loading third-party code that implements type providers to type things at compile time. Thus, I'm not sure if your hostility is well placed: are you completely opposed to third party code implementing a plug-in type system - which will necessarily require an API between it and the compiler? Or is it that the IDE folks have used this stuff that the compiler already has, and made it easier to use - are you opposed to making things easier to use? Or is it static typing that you don't like, and would rather the type providers be implemented entirely at runtime (which would severely limit their benefits, IMO).

By barrkel at Mon, 2011-10-10 11:01 | login or register to post comments

Such a trollish comment

Such a trollish comment would deserve a more trollish reply than the following.

I am yet to find a language with compile-time metaprogramming capabilities that work well and mix well with industrial needs, among which Intellisense actually figures. For this reason this addition to F# is very welcome: it offers something that is useful and powerful, and which also mixes well with concrete developer (such as myself) needs.

Your hissy fit is truly misplaced, there is nothing in common with COM and such.

By giuseppemag at Wed, 2011-10-12 08:43 | login or register to post comments

Reminds me of

Reminds me of Gosu's "Open Type System"?

By matthias becker at Mon, 2011-10-10 10:27 | login or register to post comments

Lambda the Ultimate

User login

Navigation