5 ms·

Type providers are boss. Why doesn’t every language type system have this feature by now?!

by owlstuffing 3y ago

Akronymus 3y ago
Because they are pretty annoying to implement and most are quite fragile
- eddythompson80 3y ago
  They are only as fragile as your type source.
  - FrustratedMonky 3y ago
    Maybe not 'fragile' as in buggy, not buggy, but I found them to be 'quirky'. Sometimes stop working unless I close /re-open VScode. Stuff like that. And other downfall. Do they still not work with DOTNET Core??
    - chusk3 3y ago
      They've worked for several years now on dotnet, but the type provider author has to do some work to allow their type provider to compile and target that runtime.
- owlstuffing 3y ago
  Yep, implementing one (a solid one) is hardcore. But think about it. Building, say, an XML or SQL type provider is a big deal. Doing it right requires special talent, because you are essentially building a transpiler to seamlessly interface with F#. But this is also it’s greatest strength. Having direct, type-safe access to structured data is truly awesome. What else compares? Certainly not conventional code gen.
  - Akronymus 3y ago
    Oh, don't get me wrong: Type providers are absolutely fantastic. Just, they are such a complex beast, most implementations I used so far are pretty fragile, at best. But tbh, even a fragile one is surprisingly useful
eddythompson80 3y ago
I got downvoted on the typescript subreddit when I mentioned how Type providers work in F# because "nah, it can't be working that way. The compiler can't be making http requests to make up types for an API" smh.
- Smaug123 3y ago
  In fairness it is rather terrifying :P personally I pull all necessary information into some form of version-controlled storage, and then have a test to assert that the remote information is consistent with the stored version. Life's too short to have nondeterministic builds.
  - eddythompson80 3y ago
    yeah that's fair. That's what I landed on too, and would think anyone using it seriously would be doing the same. But the fact that you could extend the compiler to program your own code generation in F# itself is amazing. Comptime in Zig reminds me of this too. I'd have to think OCaml has something similar, but I'm not too familiar with it.
    - owlstuffing 3y ago
      Java has this too with the Manifold[1] project. It’s mind blowing. 1. https://github.com/manifold-systems/manifold https://github.com/manifold-systems/manifold
      - eddythompson80 3y ago
        woah, I had no idea. That seems pretty cool
- PartiallyTyped 3y ago
  SQLX has entered the chat [1]. [1] https://github.com/launchbadge/sqlx https://github.com/launchbadge/sqlx
CharlieDigital 3y ago
Couldn't these also be done in C# via source generators?
- AlexErrant 3y ago
  No. > How do Source Generators compare with Type Providers in F#? > If you’re an F# programmer (or familiar with the language), then you might have heard of Type Providers. Source Generators were inspired in part by Type Providers, but there are several differences that make them distinct. The main difference is that Type Providers are a part of the F# language proper and emit types, properties, and methods in-memory based on an external source. Source Generators are a compiler feature that analyzes C# source code, optionally with other files, emits C# source code to include back into a compilation. https://devblogs.microsoft.com/dotnet/introducing-c-source-generators/ https://devblogs.microsoft.com/dotnet/introducing-c-source-g...
  - CharlieDigital 3y ago
    I get that the mechanisms are different, but the end result is the same. Edit: sample here with a JSON template: https://github.com/CharlieDigital/dn7-source-generators https://github.com/CharlieDigital/dn7-source-generators
    - AlexErrant 3y ago
      Ah, okay I thought that source generators had more limitations compared to F#. Turns out they can make arbitrary calls, including across a network, which previously I thought was only in the domain of type providers: > For Schema.NET, we do a HTTP request to get the JSON we need to build https://turnerj.com/blog/the-pain-points-of-csharp-source-generators https://turnerj.com/blog/the-pain-points-of-csharp-source-ge... Also phillipcarter says yes so I'll happily take his view over mine.
- phillipcarter 3y ago
  Yes. The mechanisms are very different of course, but both the F# and C# components involved generate types with properties, methods, etc. that can populate IntelliSense.
PartiallyTyped 3y ago
It's available to some in extend in rust, e.g. SQLX [1] allows you to typecheck queries. [1] https://github.com/launchbadge/sqlx https://github.com/launchbadge/sqlx

Type providers are boss. Why doesn’t every language type system have this feature by now?!

Akronymus 3y ago

Because they are pretty annoying to implement and most are quite fragile

eddythompson80 3y ago
They are only as fragile as your type source.
- FrustratedMonky 3y ago
  Maybe not 'fragile' as in buggy, not buggy, but I found them to be 'quirky'. Sometimes stop working unless I close /re-open VScode. Stuff like that. And other downfall. Do they still not work with DOTNET Core??
  - chusk3 3y ago
    They've worked for several years now on dotnet, but the type provider author has to do some work to allow their type provider to compile and target that runtime.
owlstuffing 3y ago
Yep, implementing one (a solid one) is hardcore. But think about it. Building, say, an XML or SQL type provider is a big deal. Doing it right requires special talent, because you are essentially building a transpiler to seamlessly interface with F#. But this is also it’s greatest strength. Having direct, type-safe access to structured data is truly awesome. What else compares? Certainly not conventional code gen.
- Akronymus 3y ago
  Oh, don't get me wrong: Type providers are absolutely fantastic. Just, they are such a complex beast, most implementations I used so far are pretty fragile, at best. But tbh, even a fragile one is surprisingly useful

eddythompson80 3y ago

I got downvoted on the typescript subreddit when I mentioned how Type providers work in F# because "nah, it can't be working that way. The compiler can't be making http requests to make up types for an API" smh.

Smaug123 3y ago
In fairness it is rather terrifying :P personally I pull all necessary information into some form of version-controlled storage, and then have a test to assert that the remote information is consistent with the stored version. Life's too short to have nondeterministic builds.
- eddythompson80 3y ago
  yeah that's fair. That's what I landed on too, and would think anyone using it seriously would be doing the same. But the fact that you could extend the compiler to program your own code generation in F# itself is amazing. Comptime in Zig reminds me of this too. I'd have to think OCaml has something similar, but I'm not too familiar with it.
  - owlstuffing 3y ago
    Java has this too with the Manifold[1] project. It’s mind blowing. 1. https://github.com/manifold-systems/manifold https://github.com/manifold-systems/manifold
    - eddythompson80 3y ago
      woah, I had no idea. That seems pretty cool
PartiallyTyped 3y ago
SQLX has entered the chat [1]. [1] https://github.com/launchbadge/sqlx https://github.com/launchbadge/sqlx

CharlieDigital 3y ago

Couldn't these also be done in C# via source generators?

AlexErrant 3y ago
No. > How do Source Generators compare with Type Providers in F#? > If you’re an F# programmer (or familiar with the language), then you might have heard of Type Providers. Source Generators were inspired in part by Type Providers, but there are several differences that make them distinct. The main difference is that Type Providers are a part of the F# language proper and emit types, properties, and methods in-memory based on an external source. Source Generators are a compiler feature that analyzes C# source code, optionally with other files, emits C# source code to include back into a compilation. https://devblogs.microsoft.com/dotnet/introducing-c-source-generators/ https://devblogs.microsoft.com/dotnet/introducing-c-source-g...
- CharlieDigital 3y ago
  I get that the mechanisms are different, but the end result is the same. Edit: sample here with a JSON template: https://github.com/CharlieDigital/dn7-source-generators https://github.com/CharlieDigital/dn7-source-generators
  - AlexErrant 3y ago
    Ah, okay I thought that source generators had more limitations compared to F#. Turns out they can make arbitrary calls, including across a network, which previously I thought was only in the domain of type providers: > For Schema.NET, we do a HTTP request to get the JSON we need to build https://turnerj.com/blog/the-pain-points-of-csharp-source-generators https://turnerj.com/blog/the-pain-points-of-csharp-source-ge... Also phillipcarter says yes so I'll happily take his view over mine.
phillipcarter 3y ago
Yes. The mechanisms are very different of course, but both the F# and C# components involved generate types with properties, methods, etc. that can populate IntelliSense.

PartiallyTyped 3y ago

It's available to some in extend in rust, e.g. SQLX [1] allows you to typecheck queries. [1] https://github.com/launchbadge/sqlx https://github.com/launchbadge/sqlx