A Peek into F# 4.1 • Hacker News Board

Re: A Peek into F# 4.1

#11

Post by smoothdeveloper » Fri, Jul 29, 2016, 1:24 AM UTC

saosebastiao wrote: post #2

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 ne…

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).

Re: A Peek into F# 4.1

#12

Post by catnaroek » Fri, Jul 29, 2016, 1:29 AM UTC

KirinDave wrote: post #6

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.

If it only had an actual module system - that is, an ML-style one...

Re: A Peek into F# 4.1

#13

Post by cloudroutine » Fri, Jul 29, 2016, 1:43 AM UTC

saosebastiao wrote: post #2

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 ne…

Considering the two existing ways to defines structs are

  type S = struct val X:int end
  type [] 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/...

Re: A Peek into F# 4.1

#14

Post by cloudroutine » Fri, Jul 29, 2016, 1:48 AM UTC

smoothdeveloper wrote: post #8

douche wrote: post #4

Earlier quoted context omitted.

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.

Consider using https://github.com/fsprojects/FSharpLint I'm not sure if it is integrated to ionide yet.

it is for atom, not yet for vscode

Re: A Peek into F# 4.1

#15

Post by Lewisham » Fri, Jul 29, 2016, 1:52 AM UTC

ElliotH wrote: post #3

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.

Can you point me to instructions for this setup? I'd love to try F# (having dabbled in Haskell) on macOS, but I keep getting the feeling that F# really needs Visual Studio to shine... which is a feeling which may or may not be accurate.

Re: A Peek into F# 4.1

#16

Post by smoothdeveloper » Fri, Jul 29, 2016, 2:02 AM UTC

Lewisham wrote: post #15

ElliotH wrote: post #3

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.

Can you point me to instructions for this setup? I'd love to try F# (having dabbled in Haskell) on macOS, but I keep getting the feeling that F# really needs Visual Studio to shine... which is a feeling which may or may not be accurate.

  brew install mono
  brew cask install visual-studio-code

once you are in vscode, install ionide: http://ionide.io

You are ready to script (or more) with a great / lightweight editor.

Re: A Peek into F# 4.1

#17

Post by MichaelGG » Fri, Jul 29, 2016, 2:37 AM UTC

akra wrote: post #5

saosebastiao wrote: post #2

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 ne…

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 rec…

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.

Re: A Peek into F# 4.1

#18

Post by louthy » Fri, Jul 29, 2016, 2:37 AM UTC

Lewisham wrote: post #15

ElliotH wrote: post #3

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.

Can you point me to instructions for this setup? I'd love to try F# (having dabbled in Haskell) on macOS, but I keep getting the feeling that F# really needs Visual Studio to shine... which is a feeling which may or may not be accurate.

If you don't want to use mono and want to use MS's new cross-platform version of the .NET Framework, you can use .NET Core [1] (then follow the sibling's advice on using VSCode and Ionide)

[1] https://www.microsoft.com/net/core#macos

Re: A Peek into F# 4.1

#19

Post by ElliotH » Fri, Jul 29, 2016, 2:37 AM UTC

Lewisham wrote: post #15

ElliotH wrote: post #3

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.

Can you point me to instructions for this setup? I'd love to try F# (having dabbled in Haskell) on macOS, but I keep getting the feeling that F# really needs Visual Studio to shine... which is a feeling which may or may not be accurate.

I followed the section called "Getting Started with F# 4.1 on .NET Core" in the post. Worked well for me. YMMV ofc.

Re: A Peek into F# 4.1

#20

Post by KirinDave » Fri, Jul 29, 2016, 2:43 AM UTC

catnaroek wrote: post #12

KirinDave wrote: post #6

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.

If it only had an actual module system - that is, an ML-style one...

That is by far it's worst feature. I totally agree.