Live data from Hacker News

.NET Fiddle adds F#

dotnetfiddle.net

21–30 of 72 posts

Re: .NET Fiddle adds F#

#21

Cool to "see" F# in action. Like the union types, but not so much the list operations; seems more natural to: [1;2;3;4] filter isEven sum vs. List.filter isEven [1;2;3;4] |> List.sum in Scala it's: List(1,2,3,4) filter isEven sum Of course I'm not familiar with F# so don't know all of the WIN within (Type Providers, for example, are very impressive, would love to see that on the Scala side of the fence one day).

In F#, most pipelined operations are expressed using the pipeline operator all the way.

[1; 2; 3; 4] |> List.filter isEven |> List.sum

That way you maintain the same operator order as you do in Scala, while maintaining some consistency with currying.

In addition, you can add other functions really simply while still maintaining the order.

[1; 2; 3; 4] |> List.filter isEven |> List.sum |> printfn "%i"

Re: .NET Fiddle adds F#

#22

Cool to "see" F# in action. Like the union types, but not so much the list operations; seems more natural to: [1;2;3;4] filter isEven sum vs. List.filter isEven [1;2;3;4] |> List.sum in Scala it's: List(1,2,3,4) filter isEven sum Of course I'm not familiar with F# so don't know all of the WIN within (Type Providers, for example, are very impressive, would love to see that on the Scala side of the fence one day).

The most common way to format code like that in F# would be something like let evenSum = [1;2;3;4] |> List.filter isEven |> List.Sum

Using |> is a win for two reasons - code flows more naturally, and the type inferencing works better. e.g. List.Map (fun d -> d.Hour) [DateTime.Now] does not compile, but [DateTime.Now] |> List.map (fun d -> d.Hour) does.

Re: .NET Fiddle adds F#

#23

Cool to "see" F# in action. Like the union types, but not so much the list operations; seems more natural to: [1;2;3;4] filter isEven sum vs. List.filter isEven [1;2;3;4] |> List.sum in Scala it's: List(1,2,3,4) filter isEven sum Of course I'm not familiar with F# so don't know all of the WIN within (Type Providers, for example, are very impressive, would love to see that on the Scala side of the fence one day).

I guess it's all a matter of what you're used to, because coming from ML-family languages like F# and Haskell, the first thing you wrote doesn't really make any sense to me. In the ML family like F# is, you put the function (e.g. "filter isEven") before the argument ([1;2;3;4]).

Re: .NET Fiddle adds F#

#24
post #22

Cool to "see" F# in action. Like the union types, but not so much the list operations; seems more natural to: [1;2;3;4] filter isEven sum vs. List.filter isEven [1;2;3;4] |> List.sum in Scala it's: List(1,2,3,4) filter isEven sum Of course I'm not familiar with F# so don't know all of the WIN within (Type Providers, for example, are very impressive, would love to see that on the Scala side of the fence one day).

The most common way to format code like that in F# would be something like let evenSum = [1;2;3;4] |> List.filter isEven |> List.Sum Using |> is a win for two reasons - code flows more naturally, and the type inferencing works better. e.g. List.Map (fun d -> d.Hour) [DateTime.Now] does not compile, but [DateTime.Now] |> List.map (fun d -> d.Hour) does.

That seems odd. It seems that `arg |> func` would simply be sugar for `func arg` (or a function that accomplished this). Why are they not equivalent?

Re: .NET Fiddle adds F#

#26
post #22

Earlier quoted context omitted.

The most common way to format code like that in F# would be something like let evenSum = [1;2;3;4] |> List.filter isEven |> List.Sum Using |> is a win for two reasons - code flows more naturally, and the type inferencing works better. e.g. List.Map (fun d -> d.Hour) [DateTime.Now] does not compile, but [DateTime.Now] |> List.map (fun d -> d.Hour) does.

That seems odd. It seems that `arg |> func` would simply be sugar for `func arg` (or a function that accomplished this). Why are they not equivalent?

|> is a low priority operator, which forces evaluation to occur first on the left.

[1; 2; 3] |> List.filter (fun a -> a List.sum is the same as List.sum (List.filter (fun a -> a arg |> func is the same as func (arg)

Re: .NET Fiddle adds F#

#27

Earlier quoted context omitted.

That seems odd. It seems that `arg |> func` would simply be sugar for `func arg` (or a function that accomplished this). Why are they not equivalent?

|> is a low priority operator, which forces evaluation to occur first on the left. [1; 2; 3] |> List.filter (fun a -> a List.sum is the same as List.sum (List.filter (fun a -> a arg |> func is the same as func (arg)

Yeah, that's exactly what I thought. It doesn't explain (or I don't see it yet) why the first example he gave wouldn't compile, but the second would.

Re: .NET Fiddle adds F#

#29
post #22

Earlier quoted context omitted.

The most common way to format code like that in F# would be something like let evenSum = [1;2;3;4] |> List.filter isEven |> List.Sum Using |> is a win for two reasons - code flows more naturally, and the type inferencing works better. e.g. List.Map (fun d -> d.Hour) [DateTime.Now] does not compile, but [DateTime.Now] |> List.map (fun d -> d.Hour) does.

That seems odd. It seems that `arg |> func` would simply be sugar for `func arg` (or a function that accomplished this). Why are they not equivalent?

F# type inference runs left -> right, top -> bottom. In the first snippet, the lambda is encountered first, and the compiler has no knowledge of what the type of "d" is, so it can't assume d has a ".Hour" member. In the second snippet, the compiler has already seen the input list and knows it contains DateTimes, so when it encounters the lambda, "d" is known to be a DateTime and everything is groovy.

Re: .NET Fiddle adds F#

#30

I found F# to be rather neat. This is a great way to see for yourself.

I've done very little but it seems really concise. I like that. One place some predict it will emerge is in the Web API arena, and I could totally see that happening.

Why? What makes it better than C# in web Web API area? (honest question)
Post reply on HN