> Yet another example of how Type Providers are such a game-changer for people.

I’ve seen this statement twice on HN over the past few days, so I’m getting curious about F#. I would like to understand, however, exactly how type providers change the game.

“An F# type provider is a component that provides types, properties, and methods for use in your program.”[1]

Is there an essential difference between an F# type provider and a Haskell module (which also exports types, properties and methods)?

[1] https://docs.microsoft.com/en-us/dotnet/fsharp/tutorials/typ...

F# is based on OCaml, so it has modules similar to Haskell modules independent of Type Providers.

F# Type Providers work in the background _while developing_ to provide types to your solution. In one sense they're just a lifecycle hook to generate code: they create .Net Types and then expose those types to your development environment (ie provide/export).

In practice this means you can give some JSON to a Type Provider, it will create types that match that JSON, and then those types are made available while developing so you get live intellisense and code completion based on the content and its structure through strongly typed .Net objects.

Alternatively, if you're creating some kind of DSL: a custom type provider will allow you to translate your data files into code objects that can then be used for strongly typed interactive scripting. Say, opening CAD files and publishing them to different repos depending on number of objects, auther, etc.

The readme for the project linked in this thread shows them in action :)

Type Providers give huge comfort to working with strange data by seeing all the fields immediately and interactively exploring the data schema. It's also veerrrryyyy cool to write scripts and apps that will simply refuse to compile if their assumptions about their data sources aren't met if you're dealing with third party data, or chaotic production environments, or sloppy cowboy co-workers like myself ;)

You ever been working with a JSON response, a CSV file, or a SQL query and you're just flipping between the data and your text editor, mapping each field into your model type? Type Providers automate that mapping so that you can "teach" your code the structure of that data and work with it without having to write the boilerplate.

I've never used F#, so I might get this completely wrong, but I think they are a practical form of dependently typed programming: a type provider builds new types that depend on values in your program. If you have some sort of schema for data, a type provider could parse it and build appropriate types to hold data that conforms to the schema. A type provider for a database, say, could take a string that specifies a database connection, connect to the database, and then query it to figure out what sorts of tables it holds and then construct F# types capable of holding a record from one of the tables.

SqlProgrammabilityProvider of http://fsprojects.github.io/FSharp.Data.SqlClient/ basically does just that. I usually prefer the SqlCommandProvider part of this project, as the actual queries are transparent in your F# code.

A short article about type providers in F#: https://medium.com/@maximcus/magic-of-f-type-providers-225b1...