hubFS: THE place for F#

Cross posted from blogs.msdn.com

The F# team are thrilled to announce that Visual Studio 2010 Beta1 is now available , including the latest version of F#. Today we are also releasing a matching F# May 2009 CTP for use with Visual Studio 2008 (MSI, ZIP). Further below is a screen shot, more here.

If you’re new to F#, consider watching the PDC presentation on F# by Luca Bolognese, and the live demo of F# and other new language technologies at JAOO by Anders Hejlsberg, Where are Programming Languages Going, or else download, start playing and take the MSDN walkthrough of F# in Visual Studio 2010.

Details of all this and more is in the detailed release notes, and look for more blogging by the F# team and community about all this and more. As always we are very glad to hear your feedback on all aspects of F#, and the above updates especially. We trust you enjoy your F# programming!

Don Syme, for the F# team

The F# team at Microsoft Research and Microsoft are currently working hard towards our planned CTP release of F#. This is a follow up to the 1.9.4 release of F# as a research language.

When it comes, this release will be the first release that includes signficant improvements in the Visual Studio tools. Brian McNamara has been posting a few sneak screen shots of the project system in Visual Studio. Watch Brian's blog for more!

The project system isn't the only thing we're doing: we've done an end-to-end design review, some results of which appeared in 1.9.4, we've got improvements to F# Interactive in Visual Studio, and there are other improvements across the board, as well as some great new productivity features. We look forward to your feedback when we role this release out, and we know it will make your use of F# more productive still.

[ During the summer the F# team at MSR Cambridge had the pleasure of having Juergen van Gael working with us, prior to his starting a PhD at the University of Cambridge. Juergen looked at three topics: probabilisitic modelling with F#, some machine learning algorithms with the APG team, and topics in math libary support for F#.  Before he left Juergen wrote up his expereiences of using asynchronous workflows to parallelize some math algorithms. Here's his write up!

One caveat: asynchronous workflows can be used to do some simple CPU-intensive parallelizations, but have some overheads because at each step of the way we have to cater for the fact that tasks may be asynchronous, and this often means using operating system synchronization resources ("WaitHandles") along the way. Libraries like Parallel FX Futures will have great functionality for scheduling lots of synchronous tasks, like many of the ones used below. Juergen wrote this up before we could really make heavy us of Parallel FX so his write up doesn't mention them.

Basically, I'd say that as these technologies become widely used you should assess the characteristics of your tasks and use the right scheduling machinery for the job. Do your tasks need to perform non-blocking network or disk I/O? Then the .NET thread pool will likely have to be used in some way, because that's largely how .NET asynchronous I/O works, and F# asynchronous workflows are a reasonable way of doing this kind of programming. Are they simple synchronous computational tasks? Then Parallel FX Futures look like the right machinery there.

Anyway, over to Juergen! ]

I want to draw your attention to a feature of F# that I’ve become to like very much: asynchronous workflows. As a machine learning researcher, I often run into the scenario where I need to read in a lot of data, run a number of independent tasks (potentially in parallel) and later compute some aggregate information. A very recent example required me to compute optimal parameters for a classifier; unfortunately I could not compute gradient information and decided to brute force search over a parameter grid. Evaluating the classifier for every parameter is independent of all other evaluations though and could be done in parallel. Although asynchronous workflows are designed for other purposes, they allow you to do just this. Asynchronous workflows are a mechanism in F# to setup a computation by describing small tasks and how these tasks depend on each other. The feature that got me excited was that it is extremely simple to describe parallel tasks. Onto an example!

One way to picture an asynchronous workflows is as a directed acyclic graph where every node describes a simple computation: in F# this is represented as an Async<’a> task.

V1 = Z*Z  -----\
                \
V2 = sin(Z)    ----->  R = V1 + V2 + V3
                /
V3 = log(Z) ---/

The graph above shows a simple numerical computation which could be described with asynchronous workflows. Assume Z has some value prior to executing the computation in the graph above. It should be clear that the computations of the three v’s are independent and can be done in parallel; only after all three are computed the computation can proceed by computing R. The code snippet below shows how to describe the workflow in F#:

#light

let evals =

    let z = 4.0

    [ async { do printf "Computing z*z\n"

              return z * z };

      async { do printf "Computing sin(z)\n"

              return (sin z) };

      async { do printf "Computing log(z)\n"

              return (log z) } ]

let awr =

    async { let! vs = Async.Parallel evals

            do printf "Computing v1+v2+v3\n"

            return (Array.fold_left (fun a b -> a + b) 0.0 vs) }

let R = Async.Run awr

printf "Result = %f\n" R

First we initialize a variable evals which references a list of asynchronous computation each describing the computation of one v. It is important to note that no numerical computation is done at this point: we are just setting up the computation. Next we build another computation (awr) as a workflow by using the Async.Parallel construct. This construct takes a sequence of asynchronous workflows, schedules all of them in parallel, waits for the results and returns those packaged in a list of Async types. In the awr expression, we bind variable vs to the contents of the Async type returned by the parallel computations. Again, I want to stress that at this point we have only setup the computation. Only when we execute Async.Run do we commit the runtime to evaluate the whole workflow and wait for its results. On my machine this results in the following output:

Computing z*z

Computing sin(z)

Computing log(z)

Computing v1+v2+v3

Result = 16.629492

Although the computation we setup and executed above is trivial I hope I conveyed to you that asynchronous workflows are an interesting way to describe a parallel computation. Here is a possible implementation of a parallel matrix multiplication using asynchronous workflows. Note that in this example we chose to parallelize the computation of rows, but different granularities are possible. (Do not consider this to be a high performance, parallel matrix multiplication but rather as a workflow example.)

open Microsoft.FSharp.Collections

let ParallelMultiply A B =

    let n = Array2.length1 A

    let C = Array2.create n n 0.0

    let RowTask i =

        async { do for j=0 to n-1 do

                    for k=0 to n-1 do

                        C.[i,j] <- C.[i,j] + A.[i,k] * B.[k,j]

                do printf "Computing row %d\n" i

              }

    let p = Async.Parallel [ for i in [0..n-1] -> RowTask i ] |> Async.Ignore

    Async.Run p

    C

let n = 4

let rnd = System.Random()

let A = Array2.init n n (fun i j -> rnd.NextDouble())

let B = Array2.init n n (fun i j -> rnd.NextDouble())

printf "%A\n" A

printf "%A\n" B

let C = ParMult A B

printf "%A\n" C

F# 1.9.1.9 has been released by the F# team. To quote:

This is in general a bug fix release over 1.9.1.8, with some exceptions

• We've added two great new features:
  
  • Overloaded numeric conversion functions. The functions int, float, float32 etc. now overloaded conversion operators. For example, you can replace Int32.of_float and Int32.of_int64 and all similar operators that convert to int by just int (or int32, which is equivalent). Likewise for sbyte, byte, int16, uint16 int32, uint32, int64, uint64, nativeint, unativeint, float, float32, single, double.
    
  • Checked arithmetic Open Microsoft.FSharp.Core.Operators.Checked to get checked arithmetic versions of +, -, * and the above conversion operators.
    
• We've updated the FLinq sample The FLinq sample has been updated to use the technique outline in Don Syme's ML Workshop LINQ paper from 2006. More details to follow in blog entries.
  
• We've moved to an MSI installer for this release. This is to fix numerous installation problems with the previous Zip based installer. We will be making a ZIP available for Mono users of the compiler in due course
  

F# 1.9.1 has been released!  The 1.9.1.9 download is available at this link.

I've posted the full release notes in another blog entry. The highlights in this release are:

Well, sort of :-) One of our most recent scientific users of F# is Darren Platt, head of computational genomics at the DOE Joint Genome Institute (they sequence something like 20% of the world’s DNA - here are the stats). Darren is a co-author of the recent stunning paper on Neanderthal DNA (see screen shots below), 

Read the full blog post at http://blogs.msdn.com/dsyme/archive/2006/12/06/using-fsharp-to-help-show-we-re-not-neanderthals.aspx

The F# 1.1.12.5 release has been posted. This is mostly a minor bug-fixing release, with the exception of the first point below. Here are the full release notes.

High Precedence Application. A long-standing problem with the F# syntax is that method applications followed by property/field lookups such as obj.Method1(args).Method2(args).Property1.field2 have had to be written with very non-intuitive parentheses, e.g. ((obj.Method1(args)).Method2(args)).Property1.field2.

To fix this, this release incorporates a minor change in the F# syntax (with and without the #light syntax option). In particular, applications id(args) now have higher precedence (i.e. bind more tightly) than the dot-notation. This only applies when no spaces or other whitespace separate the identifier and the arguments.

--no-tailcalls now binary-format neutral. In prior versions the --no-tailcalls option was a global setting, hence requiring the use of special libraries that had tailcalls removed. Systems such as Mono now correctly support the .tail IL annotation and so a global version of this option is no longer required. The option is still supported, but will only affect the code being generated in the assembly currently being compiled and will not result in the selection of different runtime libraries.

Some revisions to the Microsoft.FSharp.Reflection API. Some functions have been renamed or moved to an inner module. Old versions of the functions have been marked Deprecated with an error message indicating the new version to use.

Most samples rewritten using #light.

Revert change to operator overloading made in 1.1.12.2 release.

The change to operator overloading in 1.1.12.2 was incorrect, as it disallows the use of legitimate .NET overloads. The upshot is that the basic operators now have the following signatures. These indicate that the two argument types and the return type may indeed all be different, and knowledge of the return type and the second argument type are not sufficient to resolve the overloading - a type annotation may be required to give the precise type of the first argument.

val inline (+)  : ^a -> ^b -> ^c when ^a : (static member (+)    : ^a * ^b -> ^c)
val inline (-)  : ^a -> ^b -> ^c when ^a : (static member (-)    : ^a * ^b -> ^c)
val inline ( * ): ^a -> ^b -> ^c when ^a : (static member ( * )  : ^a * ^b -> ^c)
val inline (/)  : ^a -> ^b -> ^c when ^a : (static member (/)    : ^a * ^b -> ^c)
val inline (%)  : ^a -> ^b -> ^c when ^a : (static member (%)  : ^a * ^b -> ^c)
val inline (mod): ^a -> ^b -> ^c when ^a : (static member (%)  : ^a * ^b -> ^c)

We are considering a design revision which would allow more restricted specifications of permitted overloads, but are currently erring on the side of generality, even at the cost of occasional additional type annotations.

Bug fixes.

700	F# Language	undentation should be allowed when () and {} immediately follow an "="
702	F# Compiler	unbound type variable problems for inner constrained polymorphic definitions
                        fix bug with #load in F# Interactive (module paths reference incorrect version after reload)
                        Samples101 failed to compile
                        fix minor bug with #light not at start-of-file

Below is an advertisement that was sent by MEDIT to the OCaml list.  The positions are for development in OCaml, but since they explicitly advertise for both OCaml and MS-VisualStudio.NET skills it seems likely that F# skills would also rate highly. 

THREE SOFTWARE DEVELOPERS in MOLECULAR MODELING

MEDIT SA is a French start-up providing highly specialized software and services in Molecular Modeling and Cheminformatics. Our leading edge technology is based on fast 3D protein-ligand structure comparison.

MEDIT SA is looking for 3 software developers and molecular modeling experts to develop current and new software components for structure-based drug design.

The successful candidates will possess the following skills along with a passion for innovative environment:

  - confirmed expertise in software development

  - background in protein-ligand interactions and molecular modeling

  - MS in science plus experience or PhD level

Additional background in OpenGL or OCAML or MS-VisualStudio.Net would be a decisive advantage.

MEDIT offers to qualified applicants a competitive package including Stock Options. The position is based in Palaiseau (closed to Paris)

Motivated applicants should contact François Delfaud at:

fdelfaud@medit.fr (cc fmoriaud@medit.fr)

For further information:

http://www.medit.fr

F# 1.1.12.3 is now available for download from the following URL!  As usual we're announcing this first on the hub, as a sign of thanks to hub subscribers.

http://research.microsoft.com/research/downloads/download.aspx?FUID=97881c01-9282-4fa4-84ae-533fa3f38935

A full release announcement will be made in due course. We expect this to stick as a "major release" (1.1.11.12 had some minor problems now fixed. Here is the change list:

Collected changes between v1.1.11.12 and 1.1.12.3

Lightweight syntax option. Are you sick of writing in? The #light option makes the use of certain keywords such as in optional by using indentation. See the informal language specification for details, as well as the ConcurrentLife sample and the Samples101 tutorial. Enable using #light.

First experimental cut at the Active Patterns. More details to follow on Don Syme's blog.

More modules in MLLib. Modules UInt8, Int8, Int16, UInt16 have been added.

More collections in Microsoft.FSharp.Collections. The Set and Map collections are now defined as object-oriented abstractions in Microsoft.FSharp.Collections. The corresponding MLLib modules are defined in terms of these OO abstractions.

Removed deprecated Stream module from MLLib. Minor updates to the LazyList module as a result.

--gnu-style-errors flag no longer accepts spurious integer argument.

Slight modification to overloading for +,*,/,mod.

In version 1.1.11 a slight change was made to the default overloaded signature for - operator to allow the return type to be unassociated to the two input types, as is required for overloading on the System.DateTime subtraction operator. This change was mistakenly applied to other operators, resulting in situations where type inference would report unexpected inference errors for fairly straight-forward floating point code.

Bug fixes.

    ---	F# Compiler	-R clobbers DLLs with PDBs
    ---	F# Compiler	no properties being generated for top level values
    605	F# Visual Studio VFSI scroll to caret does not always show input position
    643	F# Compiler	internal warning when unpickling override of abstract member
    655	F# Compiler	interface implementing methods marked private but included in modul_typ
    656	F# Compiler	Runtime exception TypeLoadException method 'Specialize'... tried to implicitly override a method with weaker type parameter constraints
    645	F# Debug	problems setting breakpoints in inner functions (reported by Jack Palevich - thanks Jack!)
    647	F# Compiler	lowercase constructors are incorrectly permitted
    654	F# Interactive	cannot declare delegate types interactively
    672	F# Visual Studio Unapplied methods should give signature of method overloads in error message
    671	F# Compiler	-R feature overwrites .dll file with .pdb file
    670	F# Compiler	protected access not permitted via member 'this' variables
    668	F# Language	L-R type inference with (fun x -> x * x * 1.0)
    667	F# Language	exceptions to carry line numbers?
    663	 Fix broken codegen for generalized constrained polymorphic functions
    659	F# Visual Studio Intellisense does not work in a for .. to .. do line
    676	F# Visual Studio Inappropriate popup
    644	F# Language	execution and inference for record expressions is not always left-to-right
    533	F# Release	proper uninstaller
    517	F# Compiler	fsi.exe does not process #r/#I directives for files on command line
    678	F# Library	delete very old obsolete functionality fro the 'Set' module
    679	F# Library	Add object-oriented version of immutable 'Sets' to Microsoft.FSharp.Collections
    681	F# Visual Studio hardwhite intelisense
    682	F# Compiler	field and property names with same name - allowed
    680	F# Visual Studio intelisense bugs
    665	F# Language	exprs ending in semi-expr sequences cause confusion when ending constructs which are themselves semi separated.

Changes between v1.1.11.7 and 1.1.11.12

Copy-Local reference options DLLs that are not in the GAC must be copied to an application's directory prioer to execution. This is not currently well-supported by the F# Visual Studio mode. Thus the following options are now supported by the fsc.exe compiler and are especially recommended for use from Visual Studio:

  -R           DLL     both reference the given DLL and copy it to the output directory at the end of compilation
  --copy-local FILE    copy the given file to the output directory at the end of compilation

Note that -R = -r + --copy-local. Also these switches are not required by fsi.exe which is able to resolve and load DLLs from any location.

New Installer InstallFSharp.msi. This currently always installs to the Program Files directory.

New library module Microsoft.FSharp.MLLib.Native Helpers for native interop. See library documentation.

Minor breaking change for native pointers. The F# "'a nativeptr" is now compiled as the .NET type System.IntPtr for all 'a. .NET pointers such as "int*" are now represented by "ilsigptr" types. This cange is because although .NET has a notion of a "pointer type", used in some .NET signatures, these are not "real" types, since they can't be used within generic instantiations. This is very bad for C-interop F# code, which generates generic instantiations for function and tuple values. Thus, the F# 'a nativeptr type is now always compiled as System.IntPtr, regardless of 'a (it is not type equivalent as far as F# is concerend - this is just how the type is compiled. The pseudo-type 'a ilsigptr (IL Signature Pointer) is provided if you need to call a .NET signature using a pointer type.

COMPILED and INTERACTIVE supported as standard --define in F# Interactive and compiled code This is useful as some code fragments such as Application.Run() are only needed in compiled code. Also accessing things such as resources can vary between interactive and compiled code.

Type Inference corrections for fields and records

It is implicit in the F# informal specification that record constructions should use contextual left-to-right type information to help determine the type being constructed. This is now implemented, and makes it easier to use record syntax when record member names overlap.

Types are no longer inferred from uses of class field labels alone. Previously, defining a class "C" with a value field called, say "f" meant that "f" became a scoped record label. This meant that "expr.f" would infer the type of "expr" to be "C". This is still done for _record_ labels, but is no longer done for class field labels, and instead an annotation may be needed to constrain the type of "expr" based on left-to-right type inference. A helpful warning about the deprecation of this language feature is given when this occurs. This was always meant to be the intended treatment of inference for these constructs - it was an artefact of the initial implementation that inference for record field labels was treated in this way.

Various .NET generic constraints implemented .NET generics supports a number of somewhat adhoc constraints on the structural properties of types. It is necessary for F# to support these in order to emit correct and valid generic code and make sound use of F# libraries. The syntax of the constraints is:

   when 'a : struct       // any struct, with the exception of Nullable
   when 'a : not struct   // any reference type - note - this syntax is under revision
   when 'a : (new : unit -> 'a)   // default constructor

The following F#-specific constraint has also been added:

   when 'a : null          // any reference type that supports null according to the F# pseudo-enforcement rules for prohibiting the use of null with F# types
   when default 'a : <type>  // the variable will take the given value if not otherwise instantiated or generalized

Default constructors are called using the syntax:

   new 'a()

Where 'a should be related to another annotation in the same definition, e.g. an argument of the enclosing function. This constructs is compiled as a call to System.Activator.CreateInstance<'a>().

Minor improvements and Bug Fixes

   573	F# Compiler	list equality is not tail recursive.
   613	F# Library	List.combine and List.split are not tail recursive (reported by Ralf Herbrich - thanks Ralf!)
   615	F# Interactive	FSI reflection code throws TypeLoad error for type reference within the same interaction.
   602	F# Compiler	name of type not reported in "member required" error
   120	F# Compiler	Things stored in public static fields should only be accessible via properties
   495	F# Compiler	SQL cannot load F# assemblies due to publically writable statics
   625	F# Compiler	Poor error location for error messages related to 'new' in signatures
   626	F# Library	Add 'generate' methods to IEnumerable.
   628	F# Compiler	nested ifdefs not always handled correctly (Reported by Jack Palevich - thanks Jack!)
   630	F# Compiler	Error writing assembly with F# 1.1.11.7 (reported by Lewis Bruck - thanks Lewis!)
   631	F# Compiler	System.MethodAccessException thrown by FSI.EXE (reported by Pierre Dangauthier - thanks Pierre!)
   634	F# Compiler	object expression limitations: let bound object expressions not generalized (reported by Greg Neverov - thanks Greg!)
   640	F# Compiler	record fields should be inferred from the known context type of the expression 
   639	F# Compiler	class fields are contributing to the record field environemnt
   638	F# Compiler	multiple constraints on type parameters not being correctly printed
   636	F# Compiler	simple object expressions implementing interfaces should be allowed in "let rec" without generating an iniitalization graph warning
   632	F# Debug	smoother debugging needed for inner recursive functions
   648	F# Library	Documentation for printf codes for 64-bit integers is incorrect (reported by Richard Mortier - thanks Richard!)
   650	F# Compiler	incorrectly permitting the declaration of interfaces that contain fields (reported by Robert Pickering - thanks Robert!)
   649	F# Compiler	bug in quotation template filling for typed quotations (Reported by Tomas Petricek - thanks Tomas!)
   646	F# Compiler	attributes on top level values not propagating to generated static fields, e.g. ThreadStatic (reported by Robert Pickering - thanks Robert!)
   645	F# Debug	setting breakpoints in inner functions sort of broken (reported by Jack Palevich - thanks Jack!)

See http://blogs.msdn.com/dsyme/archive/2006/08/13/696931.aspx for the full article...

Internships at MSR Cambridge (now All-Year-Around)

Are you interested in working for three months at Microsoft Research, Cambridge, on a project related to F#?  MSR Cambridge now takes interns year-round, not just in the summer months. We are keen to attract motivated and well-qualified folk to work with us on our research, and on improving or developing F# and its related tools and libraries.

...

This is a heads up that we're finalizing the new installer/uninstaller for F# and will be including it in the next release. Anyone who has worked on an installer will know there can be many niggles as you iron out the little problems on all target configurations, so please stay with us if it takes us a few iterations.

Anyway, when you get the new release,  you will see the list below at the top directory.  For Windows systems with .NET 2.0 all you will have to do is run InstallFSharp.msi. 

Don

13/07/2006  01:38               987 alternative-install-vs2003.bat
13/07/2006  01:38               872 alternative-install-vs2005.bat
13/07/2006  01:38             4,857 alternative-install.bat
13/07/2006  01:30    <DIR>          bin
13/07/2006  01:18    <DIR>          doc
13/07/2006  01:38               831 install-mono.sh
13/07/2006  01:59           727,040 InstallFSharp.msi
13/07/2006  01:18    <DIR>          lib
13/07/2006  01:37             9,623 LICENSE-fsharp.txt
13/07/2006  01:21    <DIR>          manual
13/07/2006  01:37           209,834 README-fsharp.html
13/07/2006  01:25    <DIR>          samples
13/07/2006  01:29    <DIR>          setup
13/07/2006  01:18    <DIR>          source