Version 0.6.4 of the F# compiler is now available from Microsoft Research at http://research.microsoft.com/downloads. A list of recent changes is shown further below.
It is recommended that you use F# with the recently version 1.1 of the Microsoft .NET Framework (http://msdn.microsoft.com/netframework). This is also available via Windows Update. This release of the F# compiler can also be used with the SSCLI (http://msdn.microsoft.com/net/sscli) and compiled binaries should execute on all supported platforms. Specify the --sscli flag to produce debug files suitable for use with the SSCLI. (The compiled binaries should also work correctly with Mono but I have not tried this.) A new sample is included that shows how to use F# in conjunction with Malcolm Crowe's "CSTools" Lex and Yacc parsing tools. This shows how .NET style interop allows you to use tools which were originally designed for C# with F# as well. The actions for the CSTools grammars are written in C#, but can create F# abstract syntax tree values directly. On a similar topic, the DbgClr graphical debugger comes with the downloadable .NET Framework SDK. This debugger works very well with F# code and I recommend it if you are not using Visual Studio. Thanks! Don Syme Microsoft Research, Cambridge Changes: The F# compiler, v0.6 to v0.6.4 a. Assembly version numbers can now be specified as an option to the compiler. b. A number of bug fixes related to the hashing and comparison functions that are automatically synthesized for each F# type. c. The calls required to create F# data values from C# have changed a little - MkCons() is now needed instead of Cons(). As with other aspects of interop this may change in future releases. d. Performance bugs have been fixed in relation to hashing. e. New samples have been included and the samples have been documented. f. The SSCLI is now supported. g. The problems with "gacutil" in the installer should now be fixed. Changes: The F# compiler, v0.5 to v0.6 a. Vastly simplified import of .NET assemblies b. Much improved debugging support c. Debugging even on optimized code d. Multi-dimensional arrays e. Generic code generation f. Full support for unverifiable flavour of code. g. Explicit initialization no longer needed from C# h. Imported F# assemblies no longer need to be mentioned when linking i. Minor bug fixes Details: a. Vastly simplified import of .NET assemblies Details: No more .cna files are required. You can just reference a .NET assembly directly, e.g. by specifying "-r foo.dll". Most of the .NET Framework assemblies are referenced automatically. Referencing a .NET assembly requires little or no overhead either at compile-time or runtime. b. Much improved debugging support Details: Sequence points are now generally accurate, and code ranges are also substantially better. Breakpointing also works well. Data display is better as many temporary variables are no longer shown. I recommend using "DbgClr.exe" from the .NET Framework SDK or VisualStudio.NET itself. If symbol files cannot be found when attaching to a process consider setting _NT_SYMBOL_PATH globally on your machine to include a path both to your own symbols and to the "bin" directory of your F# installation. c. Debugging even on optimized code Details: Debugging is supported even if F# and JIT optimizations are enabled. Thus, for example, you can attach to an F# process which has been compiled fully optimized and still largely use the symbols produced during compilation to view data and add breakpoints. d. Multi-dimensional arrays Details: The syntax int[,] gives a two dimensional array. The "Arr2" library gives the pseudo-parametric operations for these types. These were added partly for interop with Microsoft Excel, which for one sample makes use of multi-dimensional arrays. e. Generic code generation Details: The compiler can now produce generic code for use with Gyro and our internal versions of generics for the next version of the .NET CLR. Furthermore the standard library comes compiled in its generic flavours (see fslibg.dll, fslibptrg.dll and fslibdelg.dll). This has not been widely tested. f. Full support for unverifiable flavour of code. Details: It is still not decided if ILX closures will be compiled to delegates or virtual functions. In addition, the compilation to unverifiable code also has obvious uses. Thus for the moment ILX and the F# compiler will both support 3 flavours of generated code. The DLLs for the ILX and F# libraries follow a standard naming convention to indicate the flavour. All the flavours are provided with the release, and all are pre-compiled and installed. ilxlib.dll, fslib.dll: virtual calls, non-generic ilxlibptr.dll, fslibptr.dll: unverifiable calls, non-generic ilxlibg.dll, fslibg.dll: virtual calls, generic g. Explicit initialization no longer needed from C# Details: Previously F# code required some explicit initialization: System.Console.WriteLine(fslib._init.ToString()); System.Console.WriteLine(absil._init.ToString()); This is no longer required. Initialization will happen when you touch any of the top level bindings for an F# module that are computations (but not those that define lambda function definitions). The initialization code for that module then forces the initialization of all F# modules on which the given F# module depends (There is always a strict DAG of dependencies in F#: mutual recursion between F# modules is not yet supported. It's on the "todo" list.) However, if you want to force initialization for a particular F# module you can still do so using "System.Runtime.CompilerServices. RuntimeHelpers. RunClassConstructor" on a RuntimeTypeHandle for the corresponding F# module (you can get the RunClassConstructor via a method on System.Type). h. Imported F# assemblies no longer need to be mentioned when linking Details: Previously the F# compiler required any F# assemblies to be mentioned when linking an F# program. This is no longer required: the appropriate initialization code is automatically inserted. i. Minor bug fixes - Problem with multiple conflicting references to mscorlib now fixed. - Array comparison was not correctly implemented and comparing arrays was raising a InvalidCastException - Added a better error message for the "dangling ;" condition
