Feb 2010 New F# Compiler Bugs

The app I'm working on has a couple of really large record types. The reason I would want to have a record with a huge number of fields is to pre-calculate and keep track of a Cartesian product of two other records. It's not something I wanted to rebuild every time I needed it.

What I found was that creating and manipulating large types in F# causes the F# compiler to crash. Once you get past 300 fields or so, somehow the stack has a tendency to overflow, no matter what you set the stack size to be.

At first I thought this was a property of having modules that were too big, but that wasn't it. Then I thought it might be that some of my code has long pattern matching in it.

I emailed Microsoft tech support for F# and within minutes I was in a conversation with an engineer. He thought it was the huge matching structures too -- turns out this is a known bug -- but that wasn't it. After scripting around a bit, he also determined that huge record types just aren't happening yet in F#. The workaround is to break your types up into two pieces. Ouch.

At the same time, I also noted that computing field values when you are creating the type has a tendency to make the compiler barf when you use really long types. So, for instance, if you have a type with 200 fields and each field is being created by some bit of code (instead of a simple assignment)? That's going to hose up the compiler as well. (I am not sure of the exact number of fields or what with this -- if you get this, you'll know it) The workaround here is to pre-compute the RHS of your field assignments before you create the type, then just refer to your precomputed types.

What hurts the most? The app was working and compiling fine in 2010 beta but is just a dead hunk of bits in 2010RC.