3 ms·

> Interop is another advantage of the erasure model And, in the case of F#'s type providers, it means not having to generate zillions of types when coding agai

> Interop is another advantage of the erasure model And, in the case of F#'s type providers, it means not having to generate zillions of types when coding against some huge schema. But, on the other hand, it does give you the option to do so.

seanmcdirmid 9y ago
If the bindings are reference types, the CLR will economize their representations as long as they don't have any static state, I think. I'm not sure if F# is leveraging the DLR, but there is a lot of fun that can be had there in generating types on the fly, on par with the most dynamic languages out there. It is too bad that it has been nerfed with the UWP/AOT compilation push.
- noblethrasher 9y ago
  > If the bindings are reference types, the CLR will economize their representations as long as they don't have any static state, I think. Yep, I knew about that, but type providers don't necessarily generate generic types. So, I meant something a bit different. As you know, If Foo<T> is an ordinary generic, then T must be a CLR type, which is to say that it must be code that was somehow turned into a CLR type (usually by a compiler such as C#). But, if Foo<> is a type provider, then arbitrary code of an arbitrary language can go in between the angle brackets (which is why type providers can accept strings). Essentially, each type provider is a compiler, but the code that is generated must be expressed (or "wrapped", if you will) as a CLR type. But these types need not be generic (and usually aren't, I think). So, not having erased types in F# is akin to having a compiler that can't generate loops or subroutines†. †(Perhaps a better analogy is a compiler that can't eliminate tail-calls, since erasing everything to a certain base type (that F# lets you choose) is kind of like reusing stack frames vis-à-vis the analogy)
  - seanmcdirmid 9y ago
    It is possible to generate interface definitions in C# on the fly (at run-time), but unfortunately it requires going outside of the CLR or even the DLR. Resource usage also becomes a problem since you have to generate it in a new assembly.
    - matthewwarren 9y ago
      > It is possible to generate interface definitions in C# on the fly (at run-time), Huh, I never thought about this restriction, so you can't add a new interface with 'Reflection.Emit', you can only add a class that implements an existing Interface, is that right? > but unfortunately it requires going outside of the CLR or even the DLR. By this do you mean writing raw CLR metadata yourself and then somehow injecting it into the running process or something else? Either way, its sounds like an interesting technique, any links to how it's done?
      - seanmcdirmid 9y ago
        Using type builder, you just set the type attributes to interface and define it otherwise like a class. See https://stackoverflow.com/questions/136528/using-nets-reflection-emit-to-generate-an-interface https://stackoverflow.com/questions/136528/using-nets-reflec...
        matthewwarren 9y ago
        Thanks for the link, I see what you mean now

seanmcdirmid 9y ago

If the bindings are reference types, the CLR will economize their representations as long as they don't have any static state, I think. I'm not sure if F# is leveraging the DLR, but there is a lot of fun that can be had there in generating types on the fly, on par with the most dynamic languages out there. It is too bad that it has been nerfed with the UWP/AOT compilation push.

noblethrasher 9y ago
> If the bindings are reference types, the CLR will economize their representations as long as they don't have any static state, I think. Yep, I knew about that, but type providers don't necessarily generate generic types. So, I meant something a bit different. As you know, If Foo<T> is an ordinary generic, then T must be a CLR type, which is to say that it must be code that was somehow turned into a CLR type (usually by a compiler such as C#). But, if Foo<> is a type provider, then arbitrary code of an arbitrary language can go in between the angle brackets (which is why type providers can accept strings). Essentially, each type provider is a compiler, but the code that is generated must be expressed (or "wrapped", if you will) as a CLR type. But these types need not be generic (and usually aren't, I think). So, not having erased types in F# is akin to having a compiler that can't generate loops or subroutines†. †(Perhaps a better analogy is a compiler that can't eliminate tail-calls, since erasing everything to a certain base type (that F# lets you choose) is kind of like reusing stack frames vis-à-vis the analogy)
- seanmcdirmid 9y ago
  It is possible to generate interface definitions in C# on the fly (at run-time), but unfortunately it requires going outside of the CLR or even the DLR. Resource usage also becomes a problem since you have to generate it in a new assembly.
  - matthewwarren 9y ago
    > It is possible to generate interface definitions in C# on the fly (at run-time), Huh, I never thought about this restriction, so you can't add a new interface with 'Reflection.Emit', you can only add a class that implements an existing Interface, is that right? > but unfortunately it requires going outside of the CLR or even the DLR. By this do you mean writing raw CLR metadata yourself and then somehow injecting it into the running process or something else? Either way, its sounds like an interesting technique, any links to how it's done?
    - seanmcdirmid 9y ago
      Using type builder, you just set the type attributes to interface and define it otherwise like a class. See https://stackoverflow.com/questions/136528/using-nets-reflection-emit-to-generate-an-interface https://stackoverflow.com/questions/136528/using-nets-reflec...
      - matthewwarren 9y ago
        Thanks for the link, I see what you mean now