5 ms·

A Peek into F# 4.1

157 points by douche 10y ago

saosebastiao 10y ago
I'm not a fan of the new syntax for struct tuples, struct records, and struct unions. I feel like it could have been avoided with a lesser evil if they had followed the same approach that Scala is using for anonymous functions in the upgrade to 2.12. Specifically, don't introduce new syntax, but force your users to deal with the fact that your bytecode is now incompatible with previous versions and now requires a new minimum version for the VM. They can recompile...it's not really that big of a deal. It is far more of a big deal to rewrite all of your code than it is to upgrade your VM and recompile.
- akra 10y ago
  I definitely agree with you for tuples especially smaller tuples. As tuples get larger however performance can swing the other way. As someone who codes some F# for my day job it seems that while tuples should be easier in a functional language like F# for backwards compatibility struct tuples will be more awkward to use than in C# 7. I think they should of just bit the bullet for tuples up to a certain size. For records and unions however I think the attribute is fine. Most of the time for types of more than 3 fields say structs can be worse in performance than classes anyway. Records and unions tend to be assigned more and live longer than tuples most of the time. For unions for obvious reasons structs are not recursive in nature which with unions is required somewhat (see https://msdn.microsoft.com/en-us/library/ms229017%28v=vs.110%29.aspx https://msdn.microsoft.com/en-us/library/ms229017%28v=vs.110...). Definitely wouldn't want structs to be the default here.
  - MichaelGG 10y ago
    This tuple stuff is a mess. From the RFC: >This is based partly on the assumption that the proposed C# 7.0 tuples will use struct representations for at least some small tuple types. This is what F# had to begin with! They were sort of pushed into using a heap-allocated type via System.Tuple, in the name of compatibility with the rest of .NET. Frustrating! It's also sad to see no mention of really improved tooling, to put F# on the level of C#. MSCorp paid some lip service, well overdue since the F# guys are the ones that gave them generics which was the biggest thing technical advancement .NET had over Java.
    - phillipcarter 10y ago
      > It's also sad to see no mention of really improved tooling, to put F# on the level of C#. Could you clarify what you mean here? Perhaps I could have written more about it in the blog post, but sitting the language service atop the Roslyn Workspace layer is critical work that: 1. Gives F# a "modern" editor experience out of the box. 2. Gives F# an entry point into the large amount of Roslyn-based IDE features. Workspaces are how they "talk" to the language, so that means that they can now "talk" to F# as well. This is not possible with tooling today. This also has another big impact: F# will be able to use the CPS-based project system that is being built for C# and VB right now: https://github.com/dotnet/roslyn-project-system https://github.com/dotnet/roslyn-project-system
      - MichaelGG 10y ago
        Hmm, how much does this provide? Will this make, say, F# interactive competitive with C# interactive? (Which blew past it, despite F#'s near-decade lead.) I'm tentatively hopeful I suppose.
- smoothdeveloper 10y ago
  I actually wish a keyword was also usable for the case of reference type tuples in order to be able to disambiguate those in libraries and later switch the default. It seems the feature was implemented to answer the concern of interop with C# (which in future v7 will have shorthand syntax only for System.ValueTuple but not for System.Tuple), the language might later add better support for deconstruction without the extra keyword. For tuples which remain local, the compiler is generally good at eliding those (but not in all cases, if it is a concern, always check the optimized compiled output).
- cloudroutine 10y ago
  Considering the two existing ways to defines structs are type S = struct val X:int end type [<Struct>] R = val Y:int it's not new syntax as much as an extension of the contexts where the construct is applicable. The examples in the blog post aren't in accordance with the RFC as far as type signatures are concerned [1] The tuple decomposition is mixed in with the type sig. let getPointFromOffset (point: struct (x, y)) (offset: struct (dx, dy)) = ... ^ is totally wrong let getPointFromOffset (struct(x, y) as point) (struct (dx, dy) as offset) = ... or let getPointFromOffset ((x, y): struct(int * int)) ((dx, dy): struct(int * int)) = ... use the proper syntax, which is consistent with the rest of F# [1] https://github.com/fsharp/FSharpLangDesign/blob/master/RFCs/FS-1006-struct-tuples.md#examples-and-error-messages https://github.com/fsharp/FSharpLangDesign/blob/master/RFCs/...
- _pmf_ 10y ago
  > Specifically, don't introduce new syntax Hearing this in the context of Scala is hilarious[0]. > force your users to deal with the fact that your bytecode is now incompatible with previous versions and now requires a new minimum version for the VM. They can recompile...it's not really that big of a deal. Only in the ideal world of greenfield development. You have to ensure that the build system, bytecode enhancer, AOP injectors all are able to cope with the new bytecode format. [0] http://www.flotsam.nl/dispatch-periodic-table.html http://www.flotsam.nl/dispatch-periodic-table.html
  - premium-concern 10y ago
    >> > Specifically, don't introduce new syntax > Hearing this in the context of Scala is hilarious[0]. I'm confused, I don't see any syntax in this link. Wrong link? > You have to ensure that the build system, bytecode enhancer, AOP injectors all are able to cope with the new bytecode format. If you use Scala you usually need none of them. Problem solved.
    - ThatsWhatHappen 10y ago
      Currently no, soon yes. Currently no classloader is needed to run Scala code. However, in order to solve binary compatibility once and for all, Scala 3 (aka Dotty) adds an extra bytecode layer on top of Java bytecode. Details at https://d-d.me/talks/scaladays2015 https://d-d.me/talks/scaladays2015
      - premium-concern 10y ago
        Wrong parent? (_and_ wrong content, btw)
ElliotH 10y ago
It's pretty cool being able to get this setup on my Mac and easily play around from the command line. It makes it much more accessible as a language than when it was more closely tied to the Windows/Visual Studio ecosystem.
- douche 10y ago
  I've probably spent more time messing with F# on my Mint laptop than I have on my Windows desktop... Part of that is that F# doesn't really have the level of tooling that I've come to expect from C# in VS, with ReSharper. I would like a static analysis tool for F# that tells you when you are doing something that is legal, but dumb, as ReSharper does.
  - smoothdeveloper 10y ago
    Consider using https://github.com/fsprojects/FSharpLint https://github.com/fsprojects/FSharpLint I'm not sure if it is integrated to ionide yet.
    - cloudroutine 10y ago
      it is for atom, not yet for vscode
  - smoothdeveloper 10y ago
    On Windows / Visual Studio, consider using https://github.com/fsprojects/VisualFSharpPowerTools https://github.com/fsprojects/VisualFSharpPowerTools which has some abilities similar to Resharper.
  - jackfoxy 10y ago
    I've also had a great experience with F# power tools, which now provides linting helping me keep the code clean and follow good functional coding practices, especially shorter, simpler functions. And the renaming function it provides is about all the refactoring help I have ever needed. Works great.
  - 10y ago
KirinDave 10y ago
I wish I could convince more people of the importance of F#. It sits in such a unique place. Its Ocaml heritage gives it tons of advantages over other functional languages rolled from scratch when it's time to write server or application code, it has a class library equivalent to the Java stdlib behind it, and its focus on data processing has made it a good choice for people doing data science.
- catnaroek 10y ago
  If it only had an actual module system - that is, an ML-style one...
  - KirinDave 10y ago
    That is by far it's worst feature. I totally agree.
deleted 10y ago
[deleted]
partycoder 10y ago
I am very glad that Microsoft continues to actively support F# and I hope to see it making its way into more projects in the future.
codelike 10y ago
F# is definitely a great language. It would be amazing if the interop with Entity Framework was improved, too, with regards to code-first development. Not having a nice and easy way to define virtual properties on records and classes is something I miss a lot: http://stackoverflow.com/questions/26775760/how-to-create-a-virtual-record-field-for-entity-framework-lazy-loading http://stackoverflow.com/questions/26775760/how-to-create-a-... Not sure how difficult it would be to implement a [CliVirtual] attribute (https://fslang.uservoice.com/forums/245727-f-language/suggestions/6672675-an-clivirtual-attribute https://fslang.uservoice.com/forums/245727-f-language/sugges...), but that would definitely help and make the EF-models more readable. But in general, F# is great. I hope more people will use it.

157 points by douche 10y ago

I'm not a fan of the new syntax for struct tuples, struct records, and struct unions. I feel like it could have been avoided with a lesser evil if they had followed the same approach that Scala is using for anonymous functions in the upgrade to 2.12. Specifically, don't introduce new syntax, but force your users to deal with the fact that your bytecode is now incompatible with previous versions and now requires a new minimum version for the VM. They can recompile...it's not really that big of a deal. It is far more of a big deal to rewrite all of your code than it is to upgrade your VM and recompile.

akra 10y ago
I definitely agree with you for tuples especially smaller tuples. As tuples get larger however performance can swing the other way. As someone who codes some F# for my day job it seems that while tuples should be easier in a functional language like F# for backwards compatibility struct tuples will be more awkward to use than in C# 7. I think they should of just bit the bullet for tuples up to a certain size. For records and unions however I think the attribute is fine. Most of the time for types of more than 3 fields say structs can be worse in performance than classes anyway. Records and unions tend to be assigned more and live longer than tuples most of the time. For unions for obvious reasons structs are not recursive in nature which with unions is required somewhat (see https://msdn.microsoft.com/en-us/library/ms229017%28v=vs.110%29.aspx https://msdn.microsoft.com/en-us/library/ms229017%28v=vs.110...). Definitely wouldn't want structs to be the default here.
- MichaelGG 10y ago
  This tuple stuff is a mess. From the RFC: >This is based partly on the assumption that the proposed C# 7.0 tuples will use struct representations for at least some small tuple types. This is what F# had to begin with! They were sort of pushed into using a heap-allocated type via System.Tuple, in the name of compatibility with the rest of .NET. Frustrating! It's also sad to see no mention of really improved tooling, to put F# on the level of C#. MSCorp paid some lip service, well overdue since the F# guys are the ones that gave them generics which was the biggest thing technical advancement .NET had over Java.
  - phillipcarter 10y ago
    > It's also sad to see no mention of really improved tooling, to put F# on the level of C#. Could you clarify what you mean here? Perhaps I could have written more about it in the blog post, but sitting the language service atop the Roslyn Workspace layer is critical work that: 1. Gives F# a "modern" editor experience out of the box. 2. Gives F# an entry point into the large amount of Roslyn-based IDE features. Workspaces are how they "talk" to the language, so that means that they can now "talk" to F# as well. This is not possible with tooling today. This also has another big impact: F# will be able to use the CPS-based project system that is being built for C# and VB right now: https://github.com/dotnet/roslyn-project-system https://github.com/dotnet/roslyn-project-system
    - MichaelGG 10y ago
      Hmm, how much does this provide? Will this make, say, F# interactive competitive with C# interactive? (Which blew past it, despite F#'s near-decade lead.) I'm tentatively hopeful I suppose.
smoothdeveloper 10y ago
I actually wish a keyword was also usable for the case of reference type tuples in order to be able to disambiguate those in libraries and later switch the default. It seems the feature was implemented to answer the concern of interop with C# (which in future v7 will have shorthand syntax only for System.ValueTuple but not for System.Tuple), the language might later add better support for deconstruction without the extra keyword. For tuples which remain local, the compiler is generally good at eliding those (but not in all cases, if it is a concern, always check the optimized compiled output).
cloudroutine 10y ago
Considering the two existing ways to defines structs are type S = struct val X:int end type [<Struct>] R = val Y:int it's not new syntax as much as an extension of the contexts where the construct is applicable. The examples in the blog post aren't in accordance with the RFC as far as type signatures are concerned [1] The tuple decomposition is mixed in with the type sig. let getPointFromOffset (point: struct (x, y)) (offset: struct (dx, dy)) = ... ^ is totally wrong let getPointFromOffset (struct(x, y) as point) (struct (dx, dy) as offset) = ... or let getPointFromOffset ((x, y): struct(int * int)) ((dx, dy): struct(int * int)) = ... use the proper syntax, which is consistent with the rest of F# [1] https://github.com/fsharp/FSharpLangDesign/blob/master/RFCs/FS-1006-struct-tuples.md#examples-and-error-messages https://github.com/fsharp/FSharpLangDesign/blob/master/RFCs/...
_pmf_ 10y ago
> Specifically, don't introduce new syntax Hearing this in the context of Scala is hilarious[0]. > force your users to deal with the fact that your bytecode is now incompatible with previous versions and now requires a new minimum version for the VM. They can recompile...it's not really that big of a deal. Only in the ideal world of greenfield development. You have to ensure that the build system, bytecode enhancer, AOP injectors all are able to cope with the new bytecode format. [0] http://www.flotsam.nl/dispatch-periodic-table.html http://www.flotsam.nl/dispatch-periodic-table.html
- premium-concern 10y ago
  >> > Specifically, don't introduce new syntax > Hearing this in the context of Scala is hilarious[0]. I'm confused, I don't see any syntax in this link. Wrong link? > You have to ensure that the build system, bytecode enhancer, AOP injectors all are able to cope with the new bytecode format. If you use Scala you usually need none of them. Problem solved.
  - ThatsWhatHappen 10y ago
    Currently no, soon yes. Currently no classloader is needed to run Scala code. However, in order to solve binary compatibility once and for all, Scala 3 (aka Dotty) adds an extra bytecode layer on top of Java bytecode. Details at https://d-d.me/talks/scaladays2015 https://d-d.me/talks/scaladays2015
    - premium-concern 10y ago
      Wrong parent? (_and_ wrong content, btw)

ElliotH 10y ago

It's pretty cool being able to get this setup on my Mac and easily play around from the command line. It makes it much more accessible as a language than when it was more closely tied to the Windows/Visual Studio ecosystem.

douche 10y ago
I've probably spent more time messing with F# on my Mint laptop than I have on my Windows desktop... Part of that is that F# doesn't really have the level of tooling that I've come to expect from C# in VS, with ReSharper. I would like a static analysis tool for F# that tells you when you are doing something that is legal, but dumb, as ReSharper does.
- smoothdeveloper 10y ago
  Consider using https://github.com/fsprojects/FSharpLint https://github.com/fsprojects/FSharpLint I'm not sure if it is integrated to ionide yet.
  - cloudroutine 10y ago
    it is for atom, not yet for vscode
- smoothdeveloper 10y ago
  On Windows / Visual Studio, consider using https://github.com/fsprojects/VisualFSharpPowerTools https://github.com/fsprojects/VisualFSharpPowerTools which has some abilities similar to Resharper.
- jackfoxy 10y ago
  I've also had a great experience with F# power tools, which now provides linting helping me keep the code clean and follow good functional coding practices, especially shorter, simpler functions. And the renaming function it provides is about all the refactoring help I have ever needed. Works great.
- 10y ago

KirinDave 10y ago

I wish I could convince more people of the importance of F#. It sits in such a unique place. Its Ocaml heritage gives it tons of advantages over other functional languages rolled from scratch when it's time to write server or application code, it has a class library equivalent to the Java stdlib behind it, and its focus on data processing has made it a good choice for people doing data science.

catnaroek 10y ago
If it only had an actual module system - that is, an ML-style one...
- KirinDave 10y ago
  That is by far it's worst feature. I totally agree.

deleted 10y ago

[deleted]

partycoder 10y ago

I am very glad that Microsoft continues to actively support F# and I hope to see it making its way into more projects in the future.

codelike 10y ago

F# is definitely a great language. It would be amazing if the interop with Entity Framework was improved, too, with regards to code-first development. Not having a nice and easy way to define virtual properties on records and classes is something I miss a lot: http://stackoverflow.com/questions/26775760/how-to-create-a-virtual-record-field-for-entity-framework-lazy-loading http://stackoverflow.com/questions/26775760/how-to-create-a-... Not sure how difficult it would be to implement a [CliVirtual] attribute (https://fslang.uservoice.com/forums/245727-f-language/suggestions/6672675-an-clivirtual-attribute https://fslang.uservoice.com/forums/245727-f-language/sugges...), but that would definitely help and make the EF-models more readable. But in general, F# is great. I hope more people will use it.