Discussion: Type Providers

[gulshan]

I think this is a feature that needs some love. It is being discussed since first plan of C# 7, yet did not manage to get traction. The Roslyn repo had an issue about type providers which was closed without any meaningful discussion. The issues regarding code generators mentioned it several times. I think the main difference between code generation and type providers is the type is generated at run-time from run-time data, not at compile-time.

For the record, Type Providers generate types (classes in C#) from external data sources. Then this generated type will be used to read and use data from that source in a strongly-typed manner. The data source can be a static JSON or XML file, a structured stream of data from an URI or a database or anything else. Types can be generated from externally defined types like JSON schema or XSD or even a TypeScript definition file(generate methods also?). Or the the type can be generated after discovering the structure of the data- an JSON or XML document.

The idea of type providers came from F#. Here's how a XML type provider can be used in F#- http://fsharp.github.io/FSharp.Data/library/XmlProvider.html

[HaloFour]

Sounds like something source generators could easily solve.

[DavidArno]

Are type providers really the way to go? The more I look at type providers, the more I feel they may be a case of the emperor's new clothes. They sound great and look great in demos; but there is a whiff of over-engineering about them too.

If I have a SQL type provider, for example, then - by default - the F# compiler re-reads the schema, and regenerates its transient types, on every recompile. This doesn't seem a very efficient.

As an alternative, such a feature could be added to .net core via a CLI tooling extension:

dotnet generate-types

which reads some type provider definition file and generates the types: just once (as a default).

This would provide the same funky features of F#'s type providers, without the overheads that its "magic" incurs.

[gulshan]

As far as I have understood, type generators are like "external source -> generated C# class -> compiled binary" while type providers eliminate the middle phase. It may look inefficient, but surely useful for early prototyping scenarios and scripting. It makes sense, when the external is still in development and can change frequently. Rather than two separate steps for type generation and compiling, you always get the latest correct schema. An XML or JSON configuration file can become part of compilation process supplying strongly typed configuration. And in modern hardware, the overhead is not that significant. Once stated with ease and everything settles down, one can look into the bottlenecks and if type providers happen to be one of those, he can optimize later. Friction-less communication with external world enables new scenarios.

[JoergWMittag]

Type Providers can be easily implemented using Macros. I would much rather see one generic powerful feature (i.e. Macros) than lots of little specialized features (Type Providers). See Scala for an example of how Type Providers can be implemented using Macros.

The Scala guys are currently doing all the hard work and research on integrating macros in a statically type-safe language with complex syntax. Why not wait a couple of years and then steal all of their hard work?

[dcuccia]

I would love to see this in C#, especially with the advent of .Net Interactive and Jupyter Notebook support. The ability to interactively discover a "data API" from external sources (JSON, csv, etc) via Intellisense is potentially quite powerful.

@jeremydmiller via the Lamar project has done some Roslyn work in this domain with the LamarCodeGeneration and LamarCompiler APIs. What seems needed is augmenting the Intellisense tooling to execute and expose the types that these tools generate in-memory.

[CyrusNajmabadi]

hat seems needed is augmenting the Intellisense tooling to execute and expose the types that these tools generate in-memory.

@dcuccia Roslyn already exposes an extensible API to provide completion items inside a host (like Visual Studio). It's unclear to me why any other specific would be necessary. If those Lamar tools are generating stuff in-memory, they could feed that along to intellisense as appropriate.