Heart of Sharpness (The MSR F# Team's blog at The Hub)

Investing in F# - Making the tools and language better still

2008-07-26T16:50:00Z

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.

Software Development Engineer Positions on the F# team!

2007-10-30T22:51:00Z

The F# team is hiring! We have two positions open right now. The first is a software development engineer specializing in Visual Studio and libraries. The second is a software development engineer in test. Some extracts from the job description for the first:

We’re looking for an exceptional developer to work on integration with the Visual Studio editor and debugger, and with Technical Computing libraries. You will be a key designer/engineer on our team, responsible for significant architecture investments, implementing key features, and participating in language design. You will be working with very strong architects, engineers and researchers, often working across organizational boundaries and with the developer community.

To be successful on this team, you should possess rock solid design and development skills. You should have a strong track record of shipping secure, high quality software through all phases of the product cycle and have demonstrated successes in cross team partnerships. The ideal candidate will have 6 or more years of experience designing/shipping developer tools, strong functional (F#/Haskell/OCaml), C# and C++ coding skills, and a good understanding of Technical Computing. A MS or PhD degree in Computer Science or a related technical field is preferred.

The full details of the position are up on the Microsoft site, along with how to apply. (The job is listed as "C# team" because the F# team is a small team in the C# org). The location listed is "Redmond", but we'd be open to people looking to work in Cambridge UK for some of the time.

Juergen van Gael on Asynchronous Workflows

2007-10-18T21:55:00Z

[ 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

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

CUFP Workshop 2007 - Featuring F#

2007-08-21T17:09:00Z

The program for the 2007 Commercial Users of Functional Programming workshop is now published.

http://cufp.galois.com/

The workshop is co-located with ICFP, and will be held in Freiburg, Germany, on 4 October 2007. We had a terrific response to our call for talks, and there are twelve (!) speakers describing commercial applications, variously written in
        Caml
        Erlang
        F#
        Haskell
        ML
        Scheme

The talks are informal, and there are no proceedings. We'll just have fun learning about functional programming used to solve real problems. Do come!

Don Syme
Kathleen Fisher
Simon Peyton Jones

F# 1.9.1.9 released

2007-05-06T01:42:00Z

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

Some Q&A on F# Quotations and LINQ

2007-04-07T08:48:00Z

On the F# List Roshan James recently asked some good questions about F# quotations. I thought I'd record them here along with my answers.

-----------

Hi Roshan,

Can I evaluate a <@@ 1 + 2 @@> term to value?

The primary rationale for quotations is to allow fragments of F# syntax to be executed "by alternative means", e.g. as an SQL query via LINQ or by running on a GPU. This is the same rationale as C# LINQ Expression trees. We want to leverage heavy-hitting components that map subsets of functional programs to other execution machinery. Another example might be executing a subset of F# array code by dynamic generation of Fortran code, invocation of a vectorizing Fortran compiler and loading and invoking the resulting DLL dynamically.

The FLinq sample is the primary example of this. From academic point you might call this "offshoring staged computation". This is discussed in my paper at

http://research.microsoft.com/~dsyme/papers/ml03-syme.pdf

As an example, we have recently been re-working the SQL portion of the F# FLinq sample. This builds on top of the reworked quotations API in the 1.9.1 release (http://blogs.msdn.com/dsyme/archive/2007/04/06/f-1-9-1-released.aspx.) It now uses a combination of F# Quotations and LINQ to implement what a dynamic evaluator for Expr<’a> expressions:

val SQL : Expr<'a> -> 'a

You can then execute a subset of Expr<’a> values as database queries – some examples are shown below. We’ll release this new sample in the next couple of weeks, and you can also play around with the current FLinq sample that does things a bit differently.

SQL <@ { for c in (§db.Customers)

when c.City = "London"

-> c } @>

SQL <@ { for e in (§db.Employees)

-> e.FirstName + " " + e.LastName, e.HomePhone } @>

SQL <@ { for c in (§db.Customers)

-> (c.CustomerID,

(c.CompanyName, c.City, c.Country),

(c.ContactName, c.ContactTitle)) } @>

SQL <@ { for e in (§db.Employees)

for et in e.EmployeeTerritories

when e.City = "Seattle"

-> (e.FirstName, e.LastName, et.Territory.TerritoryDescription) } @>

All of this means we're not (yet) particularly interested in executing quotations as F# code on the CPU of the local machine. This is initially counter-intuitive to those steeped in Lisp, Scheme or staged computation, but usually the SQL sample helps people see the point.

You can compile/interpret on the CPU if you are willing to write your own interpreter or dynamic compiler for the expression trees, or translate expression fragments to LINQ and use their (somewhat limited) dynamic compiler. This is also covered briefly in the paper above.

I'm also pretty certain we will eventually support using the F# compiler to “eval” quotations, but we don’t do that yet.

Can I effectively ToString a quotation?

Printing is considerably better supported in the 1.9.1 release, though is not perfect. You may need to write your own pretty printer.

Can I introduce new syntax using a <@@ @@> term somehow?

No, this is not what quotations are for.

Finally, is the diffrence between <@ .. @> and <@@ ... @@> only

that the former is not run

Type inference applies to both. The only difference between the two is that the type from the surrounding context is not propagated through the type checking of the <@@ @@> expression.

Don

F# 1.9.1 Released!

2007-04-06T22:47:00Z

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:

Active Patterns. Active patterns give a form of extensible pattern matching on abstract values. F# active patterns allow you to pattern match against .NET object values such as XML, System.Type values and LINQ Expression trees. In this redesigned version they become an official part of the language and some novel additions give a lightweight and non-intrusive mechanism to both partial patterns, parameterized patterns and "complete" decompositions (views) of types.

Implicit Class Construction. This lovely feature makes writing classes considerably more succinct and helps to further bridge the gap between type-inferred functional programming and object-oriented programming.

Simpler Quotation Library. The F# Quotation library has been redesigned to use active patterns and to have a much simpler model of types, and as such is now much more powerful. F# Quotations are used to interoperate with LINQ, Accelerator and other meta-programming components.

Methods as first-class values. You can now use .NET methods as functions in many situations, e.g. "map File.ReadAllLines ["a.txt"; "b.txt"]"

Attributes for C Interoperability. StructLayout, FieldLayout etc. now supported

Better IntelliSense. IntelliSense on more expressions, more information in ToolTips.

Syntactic improvements, Bug fixes, Library additions and much more. A whole bunch of things here - more detail in the release notes

Have fun!

don

Posted by Andyman: HDFS - Hardware design using F#

2006-12-07T18:07:00Z

View the complete topic at: http://cs.hubfs.net/forums/thread/1202.aspx

Posted By: Andyman in Applications of F#
Subject: HDFS - Hardware design using F#
__________________________________

HDFS is a library written in F# which allows hardware to be designed, simulated and then implemented (using standard design flows via Verilog or VHDL) in FPGA's or ASIC's.

http://www.evilkid.pwp.blueyonder.co.uk/

Digital logic circuit design in F#
Structural and behavioural design styles
VHDL and Verilog netlist generation
Memory inference
Instantiation of external HDL models
Integrated simulator
Verilog co-simulation (Modelsim only at the moment)
C, C++ and C# simulation generation
Integrated waveform viewer
Resource reporting
Tree based hierarchy viewer
Small, but growing, library of utility circuits and functions

The library is based upon a project called HDCaml, authored by Tom Hawkins. For more information on HDCaml see:

http://www.confluent.org/wiki/doku.php

F# helps show we're not Neanderthals

2006-12-05T23:38:00Z

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

F# 1.1.13 now available

2006-11-30T01:41:00Z

F# 1.1.13.8 has just been posted, the first external release of F# 1.1.13, and is available for download from http://research.microsoft.com/fsharp/release.aspx. The full announcement is at http://blogs.msdn.com/dsyme/archive/2006/11/30/f-1-1-13-now-available.aspx Enjoy! The F# team, MSR Cambridge Summary of changes Language Enhancements Range Comprehensions. e.g. {1 .. 3} IEnumerable, Array and List Comprehensions. Named arguments and post-hoc property-setters 'for' loops over...(read more)

Three machine learning experts, F# Interactive, IEnumerable, a Terabyte of data and XBox Live...

2006-11-22T10:04:00Z

Cross posted from http://blogs.msdn.com/dsyme/

Ralf, Phil and Thore in the MSR Cambridge Applied Games Group have been continuing their work using F# in conjunction with the XBox Live team. Ralf amazes me with the ease with which he switches between sophisticated probabilistic modelling to writing stored procedures in C#, then back to F# Interactive to crank out another great tool or algorithm. They use F# Interactive to test and script their algorithms interactively, and they deliver the programs to the Xbox Live team as a standalone binaries.

Ralf is very keen to get across how they work with F#, since the techniques are very general and reusable. For example, he describes using IEnumerable in conjunction with F# Interactive: they can develop their algorithms using IEnumerables set up to read their entire data set, a whopping 1TB in total to process, but easily use IEnumerable combinators to map, fold, filter and truncate the streams. To me that's a natural consequence of the beauty of functional programming on top of a platform like .NET. But that's the real joy of programming languages: taking the tedium out of complex transformations and analyses, and developing a simple set of compositional primitives that work together.

Do you know why TrueSkill lets you play with your friends not against them, or have you heard about Mykel Kochenderfer's Rewad Driven Racing in Project Gotham 3?

F# Interactive Tutorial by Jon Harrop

2006-10-23T19:12:00Z

Jon Harrop has produced a very nice tutorial video showing how to use F# Interactive in Visual Studio 2005. Very recommended for those getting started with F#.

Release notes for F# 1.1.12.5

2006-09-23T12:59:00Z

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

Beginnings of a MonoDevelop mode for F#

2006-09-17T00:18:00Z

Mark Czubin has begun work on an F# mode for MonoDevelop. Will this become a community project? I hope so!

Mark - for a long time we've planned to include stable and published versions of the F# APIs for interactive lexical coloring, parsing, type checking and intellisense. Plugins for MonoDevelop and other IDEs could use these directly. Would you like to call these if we provided them in the next release?

Cheers!

Don

Three Software Developer Positions in Molecular Modelling (OCaml, Visual Studio, .NET and F# skills likely to be very welcome)

2006-09-13T12:28:00Z

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

Draft Chapter 2 of "Expert F#": Essential Language Features

2006-09-06T23:50:00Z

Syndicated from http://blogs.msdn.com/dsyme/archive/2006/09/06/DraftChapter2.aspx

[ Editors Note: there are a couple of minor issues that readers have spotted with the draft chapter

When using the F# Interactive console window with F# 1.1.12 you MUST currently place ";;" on a SEPARATE line, and not at the end of the line as shown in the book. When using it with Visual Studio you don't need the ";;" at all.
F# Interactive does not print all values in exactly the same way as shown in the book ]

I'm very glad to announce the availability of an early draft of Chapter 2 of a book on F# which I'm currently in the process of co-authoring. The projected title of the book is, unabashedly, "Expert F#". This is one of two F# books planned for publication by Apress in 2007 (having seen early drafts I can say the other one will also be great!)

The chapter covers most of the language constructs in tutorial mode, with the exception of object oriented programming, which will be covered in Chapter 3. (I hope to make a draft of Chapter 3 available fairly soon - if you'd like a very early draft then please contact me directly! )

I trust you will find this a useful resource for learning F# - it has been favourably received by people at MSR Cambridge. We'll update the draft for minor fixes, though of course the final version will be available in the book.

This is only a draft that has not undergone formal technical or copy editing, so please just ignore egregious mistakes and be patient with poor formatting and dangling symbolic cross-references (for various reasons Apress do not use Word cross-referencing and prefer to do it later in the production process). Also some Apress fonts may be used, though I have attempted to replace these in the copy circulated here.

Finally, some Word comments indicate where discrepencies exist with the current F# release.

F# 1.1.12.3 now available!

2006-08-23T23:18:00Z

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!)

F# at the ICFP programming contest

2006-08-15T12:41:00Z

Some weeks ago the International Conference on Functional Programming ran its annual programming contest. In this competition teams of any size from all over the Internet compete with each other to solve programming puzzles set by the contest organizers. Two small groups from MSR Cambridge entered on the spur of the moment, one of researchers and one of interns (and yes, the interns pipped the researchers in the final analysis!)

This year's task initially concerned writing an interpreter for a virtual machine. The specification of the virtual machine was very simple and was given as part of the problem definition. The interpreter implementation needed to be very fast as it was used to run a mini operating system which served as the basis for the rest of the contest. Many teams initially wrote their interpreters in their favourite functional or scripting language but found that they had to re-write it in C to gain the required performance.

F# is a high-level and functional language, so it's not surprising that it was excellent for the rapid design and prototyping of the interpreter. However, it also ran with excellent performance, sufficient that it is was not necessary to re-write the code in a "faster" language, and indeed the fully managed and verifiable F# implementation has a speed comparable to C implementations. The C implementations can perform faster pinned memory allocation, use native pointers in the interpreter’s state and avoid indirect and bounds-checked array access. Despite this, the F# implementation is only 10-15% slower than the fastest C implementations. The code for the F# interpreter is attached.

We looked at two performance optimizations using "unsafe" C-like techniques.

A bottleneck in a managed CLR implementation is memory access via managed arrays. To interpret one memory access instruction in the interpreter requires two bounds-checked array lookups, whereas an unmanaged implementation can get away with an addition and a pointer dereference. To avoid the array bounds-checking we tried pinning allocated arrays and using unverifiable code to access the memory without bounds checks. This can be done very elegantly in F# simply by writing low-level code that directly uses CLR byte code via inline assembly blocks. Unverifiable byte-code will give the same memory access performance as C code. However the cost of allocating a pinned array on the CLR is so large that this approach halved the performance of the interpreter in the benchmark. So although the memory access performance improved, the memory allocation performance (which is another bottleneck for a managed CLR implementation) declined to such an extent as to produce a net decrease in performance.
However, unverifiable memory access to a pinned array can still be used to improve memory access to the "registers" array in the interpreter as this array only needs to be pinned once at start-up. Also aligning elements in the registers array to 8-byte boundaries improves performance again. The code for an "unsafe" version of the F# implementation uses these optimizations through inline assembly block is also attached. It gives a performance gain of about 5%.

The whole issue of performance-impairing bounds checks could be completely and elegantly solved if the Microsoft .NET Framework 2.0 CLR implemented the no.rangecheck instruction prefix as documented in the ECMA specification, and this instruction could be immediately utilized from F# (see below). This prefix tells the JIT compiler to skip the bounds checking on an array access. So regular byte-code instructions for accessing an array can simply be marked with this prefix to eliminate the bounds-checking overhead. Of course the resulting code is still unverifiable but compared to the current approach: the array does not have to be pinned (avoiding bounds checking was the sole reason we needed to pin the arrays above) and array access code does not need to be re-factored to use a different instruction sequence. If this prefix were in the CLR then fast (albeit unsafe) array access could be implemented in F# simply by defining different array brackets, e.g.

let (.[]) (arr: 'a[]) (idx:int) = (# "no.rangecheck ldelem" arr idx : 'a #)

On the topic of memory allocation, the attached F# implementations use one CLR memory allocation for every memory allocation in the interpreted code. A more efficient scheme might be to allocate a single CLR array for the interpreter’s heap and "manage" that heap yourself. This would reduce the memory allocation performance overhead and remove one layer of indirection from memory access.

Finally, the very best C implementations reported so far used runtime code generation. We believe these results could be replicated very nicely using .NET Reflection.Emit or Lightweight code generation, though haven’t tried that.

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

2006-08-13T00:39:00Z

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.

...

New F# release candidate 1.1.11.12 now available...

2006-07-20T02:29:00Z

"you read it first on the Hub"...

A new release candidate of F# is now available! This has a bunch of bug fixes, some minor tool additions, a couple of minor language changes (see below) and, perhaps most importantly, a new installer. Here's the link to the F# release candidate 1.1.11.12, which has just gone up on the external web.

F# Compiler 1.1.11.12

Note: the last step of the installer can take several minutes, if you have Visual Studio. Please be patient. The progress bar does not progress during this time.

Note: if you have trouble installing you can still install using the "alternative-install" scripts. There is also a somewhat rudimentary installation script for Mono (run using "sh install-mono.sh").

Note: there are likely to be a few niggles - please let us know how you get on.

Here are the release notes:

  -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.

Many minor bug fixes See below

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 change 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 when these values are used as part of function and tuple values. Thus, the F# 'a nativeptr type is now always compiled as System.IntPtr, regardless of 'a (these are distinct types as far as F# type checking is concerened - 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 that is described using a pointer type.

COMPILED and INTERACTIVE supported as standard --define settings 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

Record constructions now use contextual left-to-right type information to help determine the type being constructed. This makes it easier to use record syntax when record member names overlap.

   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()        // 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()

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!)

Don for the F# team at MSR Cambridge

F# 1.1.11.8+ will include new installer

2006-07-13T01:38:00Z

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.

If the install fails you can still install the contents of the zip using alternative-install*.bat.

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

Any (minor) requests for F# 1.1.11.8?

2006-07-10T23:40:00Z

F# 1.1.11.8 is being finalized. This is mostly a bug-fix release, with lots of small but important improvements (ever noticed how that "caret" often appears just off the edge of the screen in Visual F# Interactive? Well, no more!) That said, we may squeeze in an early prototype of a new feature called "active patterns". We may also have a new installer/uninstaller (we'll keep the ZIP distribution).

F# is being used an awful lot at Microsoft Research in Cambridge (home grown users!), so we're often busy collecting feature requests from them. But why stop there? If anybody has small feature requests for this or a future version please email them to me or place them on the wiki. I'm not guaranteeing we'll get to them, but we'd love to hear your suggestions.

Don