5 ms·

Is there is a moratorium on adding IL-compatible features to F# ? If so, is it keeping pace with the additions to C# ? If not, what work is being done?

by platz 7y ago

jolux 7y ago
What’s C# got recently that doesn’t already exist in F#?
- platz 7y ago
  well C# 8.0 introduced async streams, for example
  - dgudkov 7y ago
    The async model in F# is entirely different from C#. Not sure if an equivalent of C# async streams would make sense in it.
  - adgasf 7y ago
    F# allows you to implement such features as libraries using computation expressions.
    - louthy 7y ago
      So does C# with LINQ [1]. I guess C# language development tends to lean more on concrete syntax than libraries, which is a shame, but it is possible. It's also a shame LINQ can't be extended like computation expressions. [1] https://github.com/louthy/language-ext/blob/master/LanguageExt.Core/DataTypes/Task/Task.Extensions.cs https://github.com/louthy/language-ext/blob/master/LanguageE...
  - chusk3 7y ago
    Yes, and the F# library for asynchronous sequence processing had support added for them shortly thereafter (https://fsprojects.github.io/FSharp.Control.AsyncSeq/library/AsyncSeq.html https://fsprojects.github.io/FSharp.Control.AsyncSeq/library...)
  - phillipcarter 7y ago
    It's worth noting that this isn't an "IL feature", but a new type that includes some knowledge of the type shape in the C# compiler. The existing F# package for async streams understands the new type, and it "just works" in F#.
- idnefju 7y ago
  C# are pushing for type classes https://github.com/dotnet/csharplang/issues/164 https://github.com/dotnet/csharplang/issues/164 which author of F#, previously, didn't like to add to F#. (Not hating on how he wants the language to evolve)
  - chusk3 7y ago
    For clarity, the position is that large features like TC/HKT won't be added in a way that could conflict with a later-added .net/IL version of the feature.
  - jolux 7y ago
    There are real problems with IL compatibility. There’s a reason F# doesn’t have ML functors.
- pjmlp 7y ago
  Support for .NET Native would be an example. Default interface methods, not sure about the current support state. The accessors protected private. I am also not sure if all low level programming features added to C#, taken from Midori and until C# 7 only usable from C++/CLI, are also exposed to F#.
  - JaggerJo 7y ago
    .Net Native works
    - pjmlp 7y ago
      For some definition of "works". Visual Studio tooling support is nowhere to be seen, and the github issue does least some caveats.
  - phillipcarter 7y ago
    .NET Native is being replaced by .NET Core and Mono with .NET 5, which has been the plan for some time. Doing work specifically for that toolchain might have been more meaningful 4 years ago, but the amount of investment required relative to the benefit (number of developers targeting it) would have been pretty low too. Incidentally, it also works and publishing to the store is unblocked; just not supported via the VS tooling. DIMs are set for .NET 5. Cut from Core 3.0 since quality would have been an issue. _private_ has been supported in F# for ages; _protected_ is explicitly not supported. I'd personally like to see it supported for interop but this is the language designer's call. All the low-level programming features added to C# have F# "equivalents", and I use quotes because semantics differ between the languages and so your experience using one or the other is going to be quite different depending on what you're doing. But the performance output will be the same.
JaggerJo 7y ago
Also C# IMHO is becoming a bloated language. I would actually remove features from F# not add them if I could. It’s the perfect language currently available. I use it for low level stuff (working with the new Memory and Span types) and high level stuff (building UIs with FuncUI) https://github.com/AvaloniaCommunity/Avalonia.FuncUI https://github.com/AvaloniaCommunity/Avalonia.FuncUI
phillipcarter 7y ago
Yes and no. Some things, like _protected_, are explicitly not included because they encourage a style of programming - inheritance - that is not in line with the goals of F#. But that's really the only one. All recent "IL innovations" have either already been built into F# or are set for F# 5 (such as Default Interface Members).
- platz 7y ago
  Thanks

Is there is a moratorium on adding IL-compatible features to F# ? If so, is it keeping pace with the additions to C# ? If not, what work is being done?

by platz 7y ago

Is there is a moratorium on adding IL-compatible features to F# ? If so, is it keeping pace with the additions to C# ? If not, what work is being done?

jolux 7y ago

What’s C# got recently that doesn’t already exist in F#?

platz 7y ago
well C# 8.0 introduced async streams, for example
- dgudkov 7y ago
  The async model in F# is entirely different from C#. Not sure if an equivalent of C# async streams would make sense in it.
- adgasf 7y ago
  F# allows you to implement such features as libraries using computation expressions.
  - louthy 7y ago
    So does C# with LINQ [1]. I guess C# language development tends to lean more on concrete syntax than libraries, which is a shame, but it is possible. It's also a shame LINQ can't be extended like computation expressions. [1] https://github.com/louthy/language-ext/blob/master/LanguageExt.Core/DataTypes/Task/Task.Extensions.cs https://github.com/louthy/language-ext/blob/master/LanguageE...
- chusk3 7y ago
  Yes, and the F# library for asynchronous sequence processing had support added for them shortly thereafter (https://fsprojects.github.io/FSharp.Control.AsyncSeq/library/AsyncSeq.html https://fsprojects.github.io/FSharp.Control.AsyncSeq/library...)
- phillipcarter 7y ago
  It's worth noting that this isn't an "IL feature", but a new type that includes some knowledge of the type shape in the C# compiler. The existing F# package for async streams understands the new type, and it "just works" in F#.
idnefju 7y ago
C# are pushing for type classes https://github.com/dotnet/csharplang/issues/164 https://github.com/dotnet/csharplang/issues/164 which author of F#, previously, didn't like to add to F#. (Not hating on how he wants the language to evolve)
- chusk3 7y ago
  For clarity, the position is that large features like TC/HKT won't be added in a way that could conflict with a later-added .net/IL version of the feature.
- jolux 7y ago
  There are real problems with IL compatibility. There’s a reason F# doesn’t have ML functors.
pjmlp 7y ago
Support for .NET Native would be an example. Default interface methods, not sure about the current support state. The accessors protected private. I am also not sure if all low level programming features added to C#, taken from Midori and until C# 7 only usable from C++/CLI, are also exposed to F#.
- JaggerJo 7y ago
  .Net Native works
  - pjmlp 7y ago
    For some definition of "works". Visual Studio tooling support is nowhere to be seen, and the github issue does least some caveats.
- phillipcarter 7y ago
  .NET Native is being replaced by .NET Core and Mono with .NET 5, which has been the plan for some time. Doing work specifically for that toolchain might have been more meaningful 4 years ago, but the amount of investment required relative to the benefit (number of developers targeting it) would have been pretty low too. Incidentally, it also works and publishing to the store is unblocked; just not supported via the VS tooling. DIMs are set for .NET 5. Cut from Core 3.0 since quality would have been an issue. _private_ has been supported in F# for ages; _protected_ is explicitly not supported. I'd personally like to see it supported for interop but this is the language designer's call. All the low-level programming features added to C# have F# "equivalents", and I use quotes because semantics differ between the languages and so your experience using one or the other is going to be quite different depending on what you're doing. But the performance output will be the same.

JaggerJo 7y ago

Also C# IMHO is becoming a bloated language. I would actually remove features from F# not add them if I could. It’s the perfect language currently available. I use it for low level stuff (working with the new Memory and Span types) and high level stuff (building UIs with FuncUI) https://github.com/AvaloniaCommunity/Avalonia.FuncUI https://github.com/AvaloniaCommunity/Avalonia.FuncUI

phillipcarter 7y ago

Yes and no. Some things, like _protected_, are explicitly not included because they encourage a style of programming - inheritance - that is not in line with the goals of F#. But that's really the only one. All recent "IL innovations" have either already been built into F# or are set for F# 5 (such as Default Interface Members).

platz 7y ago
Thanks