On moving code from C# to F# • Hacker News Board

Re: On moving code from C# to F#

#11

Post by UnoriginalGuy » Sat, Mar 19, 2016, 4:40 PM UTC

Delmania wrote: post #7

rtpg wrote: post #4

Is it possible to call F# code easily from C#? Or vice versa?

Yes, I have a WebAPI module written in C# that calls into an F# module for some file processing. From the C# project's perspective, the F# assembly is just another assembly with static methods. It was a great use case for me to highlight the benefits of mixed paradigm programming. By making the WebAPI module state based, it made certain operations easier, while the F# module can do the heavy lifting of processing the…

That's a confusing post. You talk about WebAPI which is all JSON/AJAX, of course you can cross communicate there, the above poster is talking about direct inter-CLR calls (which you can do but have nothing to do with WebAPI).

Re: On moving code from C# to F#

#12

Post by xeromal » Sat, Mar 19, 2016, 4:45 PM UTC

iuyoynp wrote: post #2

please dont override default scrolling behaviour, the site is unusable

For someone uninformed, what did they change? I'm able to scroll using the keyboard keys, scroll bar, and arrow keys on my keyboard. Is mobile scrolling what's broken?

Re: On moving code from C# to F#

#13

Post by wtetzner » Sat, Mar 19, 2016, 4:45 PM UTC

UnoriginalGuy wrote: post #11

Delmania wrote: post #7

Earlier quoted context omitted.

Yes, I have a WebAPI module written in C# that calls into an F# module for some file processing. From the C# project's perspective, the F# assembly is just another assembly with static methods. It was a great use case for me to highlight the benefits of mixed paradigm programming. By making the WebAPI module state based, it made certain operations easier, while the F# module can do the heavy lifting of processing the…

That's a confusing post. You talk about WebAPI which is all JSON/AJAX, of course you can cross communicate there, the above poster is talking about direct inter-CLR calls (which you can do but have nothing to do with WebAPI).

> From the C# project's perspective, the F# assembly is just another assembly with static methods.

It sounds like he's calling the F# functions directly.

Re: On moving code from C# to F#

#14

Post by benrjackson » Sat, Mar 19, 2016, 4:45 PM UTC

rtpg wrote: post #4

Is it possible to call F# code easily from C#? Or vice versa?

Consuming C# code from F# works fine.

Consuming F# code from C# works pretty well for the most part, although F# specific types are cumbersome to use (records, discriminated unions, computational expressions aka monads). This just means that if you want an F# DLL to be usable from C#, you need to think a little bit about the exposed API (perhaps by adding a C# specific wrapper).

Having said that, IMO the interop between the two is better than the interop between JVM languages like java, scala & clojure (Kotlin is probably different).

Re: On moving code from C# to F#

#15

Post by Delmania » Sat, Mar 19, 2016, 4:51 PM UTC

wtetzner wrote: post #13

UnoriginalGuy wrote: post #11

Earlier quoted context omitted.

That's a confusing post. You talk about WebAPI which is all JSON/AJAX, of course you can cross communicate there, the above poster is talking about direct inter-CLR calls (which you can do but have nothing to do with WebAPI).

> From the C# project's perspective, the F# assembly is just another assembly with static methods. It sounds like he's calling the F# functions directly.

Yes, the C# WebAPI project receives a file, and then passes it off to an F# module for processing. The WebAPI takes care of authorization, authentication, and some basic checks against the file, whereas the F# library is responsible for data processing.

Re: On moving code from C# to F#

#16

Post by tigershark » Sat, Mar 19, 2016, 5:07 PM UTC

benrjackson wrote: post #14

rtpg wrote: post #4

Is it possible to call F# code easily from C#? Or vice versa?

Consuming C# code from F# works fine. Consuming F# code from C# works pretty well for the most part, although F# specific types are cumbersome to use (records, discriminated unions, computational expressions aka monads). This just means that if you want an F# DLL to be usable from C#, you need to think a little bit about the exposed API (perhaps by adding a C# specific wrapper). Having said that, IMO the interop betw…

Yes, I agree, but you need to be really careful about tail call recursion optimisation when calling f# code from c#. In F# it is always guaranteed, in c# only on 64 bit 4 and above runtime if I remember correctly, so you can't really rely on it for production code.

Re: On moving code from C# to F#

#17

Post by bunderbunder » Sat, Mar 19, 2016, 5:16 PM UTC

UnoriginalGuy wrote: post #11

Delmania wrote: post #7

Earlier quoted context omitted.

Yes, I have a WebAPI module written in C# that calls into an F# module for some file processing. From the C# project's perspective, the F# assembly is just another assembly with static methods. It was a great use case for me to highlight the benefits of mixed paradigm programming. By making the WebAPI module state based, it made certain operations easier, while the F# module can do the heavy lifting of processing the…

That's a confusing post. You talk about WebAPI which is all JSON/AJAX, of course you can cross communicate there, the above poster is talking about direct inter-CLR calls (which you can do but have nothing to do with WebAPI).

I'm guessing the poster means an ASP.NET WebAPI controller that relies on an assembly written in F#, not a process making web API calls.

Re: On moving code from C# to F#

#18

Post by RaleyField » Sat, Mar 19, 2016, 6:11 PM UTC

tigershark wrote: post #16

benrjackson wrote: post #14

Earlier quoted context omitted.

Consuming C# code from F# works fine. Consuming F# code from C# works pretty well for the most part, although F# specific types are cumbersome to use (records, discriminated unions, computational expressions aka monads). This just means that if you want an F# DLL to be usable from C#, you need to think a little bit about the exposed API (perhaps by adding a C# specific wrapper). Having said that, IMO the interop betw…

Yes, I agree, but you need to be really careful about tail call recursion optimisation when calling f# code from c#. In F# it is always guaranteed, in c# only on 64 bit 4 and above runtime if I remember correctly, so you can't really rely on it for production code.

Wouldn't C# interface only with compiled il code and not directly with F# so any tail call optimizations in F# wouldn't depend on what you later do in C# compiler?

Re: On moving code from C# to F#

#19

Post by JBReefer » Sat, Mar 19, 2016, 6:20 PM UTC

benrjackson wrote: post #14

rtpg wrote: post #4

Is it possible to call F# code easily from C#? Or vice versa?

Consuming C# code from F# works fine. Consuming F# code from C# works pretty well for the most part, although F# specific types are cumbersome to use (records, discriminated unions, computational expressions aka monads). This just means that if you want an F# DLL to be usable from C#, you need to think a little bit about the exposed API (perhaps by adding a C# specific wrapper). Having said that, IMO the interop betw…

In general you should follow Demeter's law and not expose types behind value types if you can avoid it.

Re: On moving code from C# to F#

#20

Post by tigershark » Sat, Mar 19, 2016, 6:30 PM UTC

RaleyField wrote: post #18

tigershark wrote: post #16

Earlier quoted context omitted.

Yes, I agree, but you need to be really careful about tail call recursion optimisation when calling f# code from c#. In F# it is always guaranteed, in c# only on 64 bit 4 and above runtime if I remember correctly, so you can't really rely on it for production code.

Wouldn't C# interface only with compiled il code and not directly with F# so any tail call optimizations in F# wouldn't depend on what you later do in C# compiler?

Yeah, right, the f# compiled code will be already optimised for the tail call recursion so it can be called safely from the c# code. What I remembered applies only to the c# generated IL.