EzDevInfo.com

F# changes to OCaml [closed]

F# is derived from OCaml, but what major items are missing or added? Specifically I'm curious as to whether the resources available for learning OCaml are also useful to someone who wants to learn F#.

What are practical uses of applicative style?

I am a Scala programmer, learning Haskell now. It's easy to find practical use cases and real world examples for OO concepts, such as decorators, strategy pattern etc. Books and interwebs are filled with it.

I came to the realization that this somehow is not the case for functional concepts. Case in point: applicatives.

I am struggling to find practical use cases for applicatives. Almost all of the tutorials and books I have come across so far provide the examples of [] and Maybe. I expected applicatives to be more applicable than that, seeing all the attention they get in the FP community.

I think I understand the conceptual basis for applicatives (maybe I am wrong), and I have waited long for my moment of enlightenment. But it doesn't seem to be happening. Never while programming, have I had a moment when I would shout with a joy, "Eureka! I can use applicative here!" (except again, for [] and Maybe).

Can someone please guide me how applicatives can be used in a day-to-day programming? How do I start spotting the pattern? Thanks!

Is F# really faster than Erlang at spawning and killing processes?

Updated: This question contains an error which makes the benchmark meaningless. I will attempt a better benchmark comparing F# and Erlang's basic concurrency functionality and inquire about the results in another question.

I am trying do understand the performance characteristics of Erlang and F#. I find Erlang's concurrency model very appealing but am inclined to use F# for interoperability reasons. While out of the box F# doesn't offer anything like Erlang's concurrency primitives -- from what I can tell async and MailboxProcessor only cover a small portion of what Erlang does well -- I've been trying to understand what is possible in F# performance wise.

In Joe Armstrong's Programming Erlang book, he makes the point that processes are very cheap in Erlang. He uses the (roughly) the following code to demonstrate this fact:

-module(processes).
-export([max/1]).

%% max(N) 
%%   Create N processes then destroy them
%%   See how much time this takes

max(N) ->
    statistics(runtime),
    statistics(wall_clock),
    L = for(1, N, fun() -> spawn(fun() -> wait() end) end),
    {_, Time1} = statistics(runtime),
    {_, Time2} = statistics(wall_clock),
    lists:foreach(fun(Pid) -> Pid ! die end, L),
    U1 = Time1 * 1000 / N,
    U2 = Time2 * 1000 / N,
    io:format("Process spawn time=~p (~p) microseconds~n",
          [U1, U2]).

wait() ->
    receive
        die -> void
    end.

for(N, N, F) -> [F()];
for(I, N, F) -> [F()|for(I+1, N, F)].

On my Macbook Pro, spawning and killing 100 thousand processes (processes:max(100000)) takes about 8 microseconds per processes. I can raise the number of processes a bit further, but a million seems to break things pretty consistently.

Knowing very little F#, I tried to implement this example using async and MailBoxProcessor. My attempt, which may be wrong, is as follows:

#r "System.dll"
open System.Diagnostics

type waitMsg =
    | Die

let wait =
    MailboxProcessor.Start(fun inbox ->
        let rec loop =
            async { let! msg = inbox.Receive()
                    match msg with 
                    | Die -> return() }
        loop)

let max N =
    printfn "Started!"
    let stopwatch = new Stopwatch()
    stopwatch.Start()
    let actors = [for i in 1 .. N do yield wait]
    for actor in actors do
        actor.Post(Die)
    stopwatch.Stop()
    printfn "Process spawn time=%f microseconds." (stopwatch.Elapsed.TotalMilliseconds * 1000.0 / float(N))
    printfn "Done."

Using F# on Mono, starting and killing 100,000 actors/processors takes under 2 microseconds per process, roughly 4 times faster than Erlang. More importantly, perhaps, is that I can scale up to millions of processes without any apparent problems. Starting 1 or 2 million processes still takes about 2 microseconds per process. Starting 20 million processors is still feasible, but slows to about 6 microseconds per process.

I have not yet taken the time to fully understand how F# implements async and MailBoxProcessor, but these results are encouraging. Is there something I'm doing horribly wrong?

If not, is there some place Erlang will likely outperform F#? Is there any reason Erlang's concurrency primitives can't be brought to F# through a library?

EDIT: The above numbers are wrong, due to the error Brian pointed out. I will update the entire question when I fix it.

When are higher kinded types useful?

I've been doing dev in F# for a while and I like it. However one buzzword I know doesn't exist in F# is higher-kinded types. I've read material on higher-kinded types, and I think I understand their definition. I'm just not sure why they're useful. Can someone provide some examples of what higher-kinded types make easy in Scala or Haskell, that require workarounds in F#? Also for these examples, what would the workarounds be without higher-kinded types (or vice-versa in F#)? Maybe I'm just so used to working around it that I don't notice the absence of that feature.

(I think) I get that instead of myList |> List.map f or myList |> Seq.map f |> Seq.toList higher kinded types allow you to simply write myList |> map f and it'll return a List. That's great (assuming it's correct), but seems kind of petty? (And couldn't it be done simply by allowing function overloading?) I usually convert to Seq anyway and then I can convert to whatever I want afterwards. Again, maybe I'm just too used to working around it. But is there any example where higher-kinded types really saves you either in keystrokes or in type safety?

Handy F# snippets [closed]

There are already two questions about F#/functional snippets.

However what I'm looking for here are useful snippets, little 'helper' functions that are reusable. Or obscure but nifty patterns that you can never quite remember.

Something like:

open System.IO

let rec visitor dir filter= 
    seq { yield! Directory.GetFiles(dir, filter)
          for subdir in Directory.GetDirectories(dir) do 
              yield! visitor subdir filter} 

I'd like to make this a kind of handy reference page. As such there will be no right answer, but hopefully lots of good ones.

EDIT Tomas Petricek has created a site specifically for F# snippets http://fssnip.net/.

Why is F#'s type inference so fickle?

The F# compiler appears to perform type inference in a (fairly) strict top-to-bottom, left-to-right fashion. This means you must do things like put all definitions before their use, order of file compilation is significant, and you tend to need to rearrange stuff (via |> or what have you) to avoid having explicit type annotations.

How hard is it to make this more flexible, and is that planned for a future version of F#? Obviously it can be done, since Haskell (for example) has no such limitations with equally powerful inference. Is there anything inherently different about the design or ideology of F# that is causing this?

In what areas does F# make "absolute no sense in using"? [closed]

Don Syme in his SPLASH talk says that F# is NOT intended to be a replacement for C# even though it has the general capabilities. He goes on to say that there are areas where F# makes no sense in using, but doesn't expand on the thesis.

1. Can somebody please tell me what areas should be avoided while using F# ?
2. You could also mention areas where C# shine.

Related question:

In what areas might the use of F# be more appropriate than C#?

F# performance in scientific computing

I am curious as to how F# performance compares to C++ performance? I asked a similar question with regards to Java, and the impression I got was that Java is not suitable for heavy numbercrunching.

I have read that F# is supposed to be more scalable and more performant, but how is this real-world performance compares to C++? specific questions about current implementation are:

• How well does it do floating-point?
• Does it allow vector instructions
• how friendly is it towards optimizing compilers?
• How big a memory foot print does it have? Does it allow fine-grained control over memory locality?
• does it have capacity for distributed memory processors, for example Cray?
• what features does it have that may be of interest to computational science where heavy number processing is involved?
• Are there actual scientific computing implementations that use it?

Thanks

How to marshal multi-dimensional arrays

We have some interop code that involves matrices. I was trying to call the native DLL and for the most part it works very reliably.

I am relying on the default marshalling by .net, avoiding unmanaged pointers and rather using .net arrays for the most part, and maybe a byref here and there. The .net article says, that multidimensional arrays are implicitly marshalled as column-major one-dimensional arrays, which would be fine.

The only thing that does not seem to work, is trying to marshal a multi-dimensional array, as the F# compiler complains that float[,] is not allowed in an extern declaration. Is there any way around this limitation?

I am aware of the PinnedArray and PinnedArray2 types from the F# PowerPack, but I was looking for a solution which relies on managed pointers and - more importantly - I'd like to avoid having to include F# PowerPack as a dependency just for the PinnedArray classes.

Best approach for designing F# libraries for use from both F# and C#

I am trying to design a library in F#. The library should be friendly for use from both F# and C#.

And this is where I'm stuck a little bit. I can make it F# friendly, or I can make it C# friendly, but the problem is how to make it friendly for both.

Here is an example. Imagine I have the following function in F#:

let compose (f: 'T -> 'TResult) (a : 'TResult -> unit) = f >> a

This is perfectly usable from F#:

let useComposeInFsharp() =
    let composite = compose (fun item -> item.ToString) (fun item -> printfn "%A" item)
    composite "foo"
    composite "bar"

In C#, the compose function has the following signature:

FSharpFunc<T, Unit> compose<T, TResult>(FSharpFunc<T, TResult> f, FSharpFunc<TResult, Unit> a);

But of course I don't want FSharpFunc in the signature, what I want is Func and Action instead, like this:

Action<T> compose2<T, TResult>(Func<T, TResult> f, Action<TResult> a);

To achieve this, I can create compose2 function like this:

let compose2 (f: Func<'T, 'TResult>) (a : Action<'TResult> ) = 
    new Action<'T>(f.Invoke >> a.Invoke)

Now this is perfectly usable in C#:

void UseCompose2FromCs()
{
    compose2((string s) => s.ToUpper(), Console.WriteLine);
}

But now we have problem using compose2 from F#! Now I have to wrap all standard F# funs into Func and Action, like this:

let useCompose2InFsharp() =
    let f = Func<_,_>(fun item -> item.ToString())
    let a = Action<_>(fun item -> printfn "%A" item)
    let composite2 = compose2 f a

    composite2.Invoke "foo"
    composite2.Invoke "bar"

The question: How can we achieve first-class experience for the library written in F# for both F# and C# users?

So far, I couldn't come up with anything better than these two approaches:

1. Two separate assemblies: one targeted to F# users, and the second to C# users.
2. One assembly but different namespaces: one for F# users, and the second for C# users.

For the first approach, I would do something like this:

1. Create F# project, call it FooBarFs and compile it into FooBarFs.dll.

   • Target the library purely to F# users.
   • Hide everything unnecessary from the .fsi files.

2. Create another F# project, call if FooBarCs and compile it into FooFar.dll

   • Reuse the first F# project at the source level.
   • Create .fsi file which hides everything from that project.
   • Create .fsi file which exposes the library in C# way, using C# idioms for name, namespaces etc.
   • Create wrappers that delegate to the core library, doing the conversion where necessary.

I think the second approach with the namespaces can be confusing to the users, but then you have one assembly.

The question: none of these are ideal, perhaps I am missing some kind of compiler flag/switch/attribte or some kind of trick and there is a better way of doing this?

The question: has anyone else tried to achieve something similar and if so how did you do it?

EDIT: to clarify, the question is not only about functions and delegates but the overall experience of a C# user with an F# library. This includes namespaces, naming conventions, idioms and suchlike that are native to C#. Basically, a C# user shouldn't be able to detect that the library was authored in F#. And vice versa, an F# user should feel like dealing with a C# library.

EDIT 2:

I can see from the answers and comments so far that my question lacks the necessary depth, perhaps mostly due to use of only one example where interoperability issues between F# and C# arise, the issue of functions a values. I think this is the most obvious example and so this led me to use it to ask the question, but by the same token gave the impression that this is the only issue I am concerned with.

Let me provide more concrete examples. I have read through the most excellent F# Component Design Guidelines document (many thanks @gradbot for this!). The guidelines in the document, if used, do address some of the issues but not all.

The document is split it two main parts: 1) guidelines for targeting F# users; and 2) guidelines for targeting C# users. Nowhere does it even attempt to pretend that it is possible to have a uniform approach, which exactly echoes my question: we can target F#, we can target C#, but what is the practical solution for targeting both?

To remind, the goal is to have a library authored in F#, and which can be used idiomatically from both F# and C# languages.

The keyword here is idiomatic. The issue is not the general interoperability where it is just possible to use libraries in different languages.

Now to the examples, which I take straight from F# Component Design Guidelines.

1. Modules+functions (F#) vs Namespaces+Types+functions

   • F#: Do use namespaces or modules to contain your types and modules. The idiomatic use is to place functions in modules, e.g.:

     // library
     module Foo
     let bar() = ...
     let zoo() = ...
     
     
     // Use from F#
     open Foo
     bar()
     zoo()
     

   • C#: Do use namespaces, types and members as the primary organizational structure for your components (as opposed to modules), for vanilla .NET APIs.

     This is incompatible with the F# guideline, and the example would need to be re-written to fit the C# users:

     [<AbstractClass; Sealed>]
     type Foo =
         static member bar() = ...
         static member zoo() = ...
     

     By doing so though, we break the idiomatic use from F# because we can no longer use bar and zoo without prefixing it with Foo.

2. Use of tuples

   • F#: Do use tuples when appropriate for return values.

   • C#: Avoid using tuples as return values in vanilla .NET APIs.

3. Async

   • F#: Do use Async for async programming at F# API boundaries.

   • C#: Do expose asynchronous operations using either the .NET asynchronous programming model (BeginFoo, EndFoo), or as methods returning .NET tasks (Task), rather than as F# Async objects.

4. Use of Option

   • F#: Consider using option values for return types instead of raising exceptions (for F#-facing code).

   • Consider use the TryGetValue pattern instead of returning F# option values (option) in vanilla .NET APIs, and prefer method overloading to taking F# option values as arguments.

5. Discriminated unions

   • F#: Do use discriminated unions as an alternative to class hierarchies for creating tree-structured data

   • C#: no specific guidelines for this, but the concept of discriminated unions is foreign to C#

6. Curried functions

   • F#: curried functions are idiomatic for F#

   • C#: Do not use currying of parameters in vanilla .NET APIs.

7. Checking for null values

   • F#: this is not idiomatic for F#

   • C#: Consider checking for null values on vanilla .NET API boundaries.

8. Use of F# types list, map, set, etc

   • F#: it is idiomatic to use these in F#

   • C#: Consider using the .NET collection interface types IEnumerable and IDictionary for parameters and return values in vanilla .NET APIs. (i.e. do not use F# list, map, set)

9. Function types (the obvious one)

   • F#: use of F# functions as values is idiomatic for F#, obiously

   • C#: Do use .NET delegate types in preference to F# function types in vanilla .NET APIs.

I think these should be sufficient to demonstrate the nature of my question.

Incidentally, the guidelines also have partial answer:

... a common implementation strategy when developing higher-order methods for vanilla .NET libraries is to author all the implementation using F# function types, and then create the public API using delegates as a thin façade atop the actual F# implementation.

To summarise.

There is one definite answer: there are no compiler tricks that I missed.

As per the guidelines doc, it seems that authoring for F# first and then creating a facade wrapper for .NET is the reasonable strategy.

The question then remains regarding the practical implementation of this:

• Separate assemblies? or

• Different namespaces?

If my interpretation is correct, Tomas suggests that using separate namespaces should be sufficient, and should be an acceptable solution.

I think I will agree with that given that the choice of namespaces is such that it does not surprise or confuse the .NET/C# users, which means that the namespace for them should probably look like it is the primary namespace for them. The F# users will have to take the burden of choosing F#-specific namespace. For example:

• FSharp.Foo.Bar -> namespace for F# facing library

• Foo.Bar -> namespace for .NET wrapper, idiomatic for C#

How do I use Travis-CI with C# or F#

Travis CI continuous integration service officially supports many languages, but not C# or F#.

Can I use it with my .net projects?

Listing all permutations of a string/integer

A common task in programming interviews (not from my experience of interviews though) is to take a string or an integer and list every possible permutation.

Is there an example of how this is done and the logic behind solving such a problem?

I've seen a few code snippets but they weren't well commented/explained and thus hard to follow.

Is it possible to write a JIT compiler (to native code) entirely in a managed .NET language

I'm toying with the idea of writing a JIT compiler and am just wondering if it is even theoretically possible to write the whole thing in managed code. In particular, once you've generated assembler into a byte array how do you jump into it to begin execution?

Async POST fails on WP7 and F#

When I do let! read = from.AsyncRead buf in F#, it blocks and doesn't return until the TCP socket is dead. Why? And how do I fix it?

Its code:

module StreamUtil

open System.IO

/// copy from 'from' stream to 'toStream'
let (|>>) (from : Stream) (toStream : Stream) =
  let buf = Array.zeroCreate<byte> 1024
  let rec doBlock () =
    async {
      let! read = from.AsyncRead buf
      if read <= 0 then
        toStream.Flush()
        return ()
      else
        do! toStream.AsyncWrite(buf, 0, read)
        return! doBlock () }
  doBlock ()

It's being called from this code:

use fs = new FileStream(targPath, FileMode.CreateNew, FileAccess.ReadWrite)
do! req.InputStream |>> fs

and requested over HTTP with this code from Windows Phone 7.1 emulator:

public void Send()
{
    var b = new UriBuilder(_imageService.BaseUrl) {Path = "/images"};

    var req = WebRequest.CreateHttp(b.Uri);
    req.ContentType = "image/jpeg";
    req.Method = "POST";
    var imgLen = SelectedImage.ImageStream.Length;
    req.Headers[HttpRequestHeader.ContentLength] = imgLen.ToString(CultureInfo.InvariantCulture);
    req.Accept = "application/json";
    req.BeginGetRequestStream(RequestReady, new ReqState(req, imgLen));
}

void RequestReady(IAsyncResult ar)
{
    var state = (ReqState)ar.AsyncState;
    var req = state.Request;

    var reqStream = req.EndGetRequestStream(ar);

    SmartDispatcher.BeginInvoke(() =>
        {
            using (var sw = new StreamWriter(reqStream))
            using (var br = new BinaryReader(SelectedVoucher.ImageStream))
            {
                var readBytes = br.ReadBytes(state.ImgLen);

                // tried both 2
                sw.Write(readBytes);
                //sw.Write(Convert.ToBase64String(readBytes));
                sw.Flush();
                sw.Close();
            }
            req.BeginGetResponse(ResponseReady, req);
        });
}

// WHY U NO GET CALLED???
void ResponseReady(IAsyncResult ar)
{
    try
    {
        var request = (HttpWebRequest)ar.AsyncState;
        var response = request.EndGetResponse(ar);

        SmartDispatcher.BeginInvoke(() =>
            {
                var rdr = new StreamReader(response.GetResponseStream());
                var msg = rdr.ReadToEnd();

                var imageLocation = response.Headers["Location"];

                Debug.WriteLine(msg);
                Debug.WriteLine(imageLocation);
            });
    }
    catch (WebException ex)
    {
        Debug.WriteLine(ex.ToString());
    }
    catch (Exception ex)
    {
        Debug.WriteLine(ex.ToString());
    }
}

Unsuccessfully. The ResponseReady callback is never reached.

Meanwhile, this code works excellent:

open System
open System.Net.Http // WebAPI nuget

let sync aw = Async.RunSynchronously aw

let postC<'a> (c : HttpClient) (r : Uri) (cont : HttpContent) =
  let response = sync <| Async.AwaitTask( c.PostAsync(r, cont) )
  let struc:'a = sync <| deserialize<'a> response
  response, struc

let withContent<'a> (fVerb : (HttpClient -> Uri -> HttpContent -> _ * 'a))=
  let c = new HttpClient()
  fVerb c

[<Test>]
let ``POST /images 201 + Location header`` () =
  let post = withContent<MyImage> postC
  let bytes = IO.File.ReadAllBytes("sample.jpg")
  let hash = SHA1.Create().ComputeHash(bytes) |> Convert.ToBase64String
  let pic = new ByteArrayContent(bytes)
  pic.Headers.Add("Content-Type", "image/jpeg")
  pic.Headers.Add("X-SHA1-Hash", hash)
  let resp, ri = (resource "/images", pic) ||> post

  resp.StatusCode =? Code.Created
  ri.sha1 =? hash
  mustHaveHeaders resp

I couldn't get Fiddler2 working with WP7.

F# development and unit testing?

I just got started with F#, which is my first functional language. I have been working quasi-exclusively with C#, and enjoy a lot how F# leads me to re-think how I write code. One aspect I find a bit disorienting is the change in the process of writing code. I have been using TDD for years in C# now, and really appreciate to have unit tests to know where I am at.

So far, my process with F# has been to write some functions, play with them with the interactive console until I am "reasonably" sure they work, and tweak & combine. This works well on small-scale problems like the Euler Project, but I can't imagine building something large that way.

How do people approach unit testing and building a test suite for a F# program? Is there an equivalent to TDD? Any pointers or thoughts are appreciated.