This is a guest post by Anh-Dung Phan and Vasily Kirichenko, F# community developers and contributors to the superb Visual F# Power Tools extension for Visual Studio.  – Visual F# Team

We are pleased to tell you about the Visual F# Power Tools, a Visual Studio extension aimed at providing extended tooling for F# in Visual Studio. You can download it today from the Visual Studio gallery.

The goal of the extension is to complement the standard Visual Studio F# tooling by adding missing features such as semantic highlighting, rename refactoring, find all references, metadata-as-source, and more.

What’s particularly special about this project is that it's a collective effort of the F# open source community. We work alongside the Visual F# Team at Microsoft in order to provide a complete toolset for F# users in Visual Studio.

This project is about 1.5 years old now, and has received overwhelming positive feedback from the F# community. Today we are excited to share this effort, and the story behind it, with a broader audience.

…

To continue reading, please see the full post on the .NET Blog.

The Visual F# team is now publishing to the unified .NET Blog, along with Roslyn, ASP.NET, the core .NET Framework team, and others.  This will give Visual F# content much more exposure, with posts shown alongside those of other key .NET technologies.

Please update your bookmarks and RSS readers.  We will continue to cross-post here for a few months during the transition.

…

To continue reading, please see the full post on the .NET Blog. The Visual F# team is now publishing to the unified .NET Blog, along with Roslyn, ASP.NET, the core .NET Framework team, and others.  This will give Visual F# content much more exposure, with posts shown alongside those of other key .NET technologies.

Please update your bookmarks and RSS readers.  We will continue to cross-post here for a few months during the transition.

Mads and Dustin showed off these stylish little numbers at BUILD and ever since we've been getting pinged by community members wanting to know where they can get their very own so they too can show their passion for their favorite programming language(s).

 

These were originally team t-shirts from years ago and every time one of us wears one of them out at a talk or a conference without fail you let us know how much you'd love to get your hands on one. Finally Visual Basic MVP Jim Wooley shot me a tweet saying "Just put it on CafePress.com already!". Great idea, Jim! We actually lost the pattern but I've come up with a couple of different designs based on the original I want to share with you and hear what you think.

…

To continue reading (and to see the F# shirts), please see the full post on the .NET blog.

The Visual F# team is now publishing to the unified .NET Blog, along with Roslyn, ASP.NET, the core .NET Framework team, and others.  This will give Visual F# content much more exposure, with posts shown alongside those of other key .NET technologies.

Please update your bookmarks and RSS readers.  We will continue to cross-post here for a few months during the transition.

Back in November, we described the F# 4.0 features that were completed in time for the Visual Studio 2015 Preview build. New features like constructors as first-class functions, simplified mutable/ref values, a normalized collections API, and more were warmly received.  We didn’t stop there, though!

This post describes the F# 4.0 work that’s been completed since Preview.  Together with the features announced earlier, this completes the planned feature set for F# 4.0. Bug fixes and performance optimizations will continue to be accepted up until VS 2015 RTM. The F# bits that ship with today’s RC build map to commit 76ae08d.

…

To continue reading, please see the full post on the .NET Blog. The Visual F# team is now publishing to the unified .NET Blog, along with Roslyn, ASP.NET, the core .NET Framework team, and others.  This will give Visual F# content much more exposure, with posts shown alongside those of other key .NET technologies.

Please update your bookmarks and RSS readers.  We will continue to cross-post here for a few months during the transition.

• 37 code contributors
• 300 pull requests
• 420 issues
• 488 commits

On this occasion we offer our thanks to our contributors and users, and ask that you join us in continuing to make F# and the Visual F# tools the best they can be!

This brings us closer to the longtime home of the F# Open Edition, addresses one of our top bugs, and puts us on the same hosting platform as other great Microsoft open source projects like .NET Core, Typescript, and (soon) Roslyn.

We ask our community to move all development activities to the GitHub repo, starting today.

A few bits of bookkeeping:

• History will remain fully intact. We are just re-hosting our git repo from Codeplex to GitHub.
• PRs remaining on Codeplex will be discussed, serviced, and closed from there, they do not need to be migrated. We will merge those changes and push them to GitHub.
• Issues open on Codeplex will remain there for the time being, with a migration plan TBD.
• Discussions on Codeplex will not be migrated. Any new “discussions” should be opened as GitHub issues.

Over the past months, we have made an impressive amount of progress together on F# 4.0 and the next version of the Visual F# Tools.  There is still plenty of work remaining here.

With the goal of shipping a high-quality, enterprise-grade F# language and toolchain in Visual Studio 2015, it’s come time to wind down new feature development for F# 4.0, and start focusing our efforts on quality validation and stabilization.

We plan to use the following schedule as the roadmap to releasing 4.0:

12/8/2014 – Last day for feature-level PRs to be submitted.  
12/19/2014 – Submitted feature PRs have been given initial review and are either approved or cut for F# 4.0.  Iteration and fixups of approved PRs continues past this date.   
1/9/2015 – Approved feature PRs are complete and integrated. Visual F# Tools 4.0 is considered “feature complete.”
1/23/2015 – Visual F# Tools 4.0 considered to be at “release candidate” stage.

New PRs containing bug fixes or performance improvements are encouraged throughout this time, though the bar for accepting such changes will naturally rise as we get closer to the end of January.

This is a short runway, and we understand that not everything which was once planned will ready by these dates. Keep in mind that once Visual F# 4.0 ships, we will be releasing regular F# update packages, just as we did with the Visual F# 3.1.1 and 3.1.2 releases.  High-quality features and fixes that didn’t quite make it to F# 4.0 will of course be considered for update releases.

As we lock down feature work over the coming weeks, we call on F# community developers to continue contributing by focusing on quality and testing:

-    Install the VS 2015 Preview and the F# 4.0 preview update and try them out on your own projects
-    File bugs at https://visualfsharp.codeplex.com/
-    Submit fixes for open bugs
-    Review, test, and comment on open PRs

We are looking forward to this last stage of the development cycle, and to an incredible Visual F# Tools 4.0 release next year!

We recommend that you download and install the latest Visual F# 4.0 bits here, as an update for VS 2015 Preview.  This blog reviews the key enhancements and changes completed up through this update package.  VS 2015 Preview ships with F# components matching commit 3a27cd8 (from October 12).  The update brings the F# bits up to date with commit afe5027 (from November 11).

Overview

More to come

Today’s release is just an early preview of F# 4.0 and the latest Visual F# Tools. There is still a lot more language and tooling work planned, but we think now is a good time to step back and talk about what’s been completed so far.  There’s quite a lot! In-progress features and up-to-date status can be found on our Codeplex page.

By and for the F# community

Since enabling community contributions to the compiler in April, then opening up the F# Visual Studio stack in June, the F# language and Visual F# IDE tooling stack has been developed in full partnership with the open source developer community. In just this short time, the Visual F# project has received a stunning 159 pull requests from 32 developers, of which we have so far been able to apply 90.

More so than any previous release, Visual F# 4.0 represents the hard work, dedication, and contagious enthusiasm of the F# open source community.  Much of the new content described below was developed largely or completely by non-Microsoft contributors. The community, in partnership with Microsoft Open Technologies, the F# Software Foundation, and others, have developed F# into a mature, cross-platform, functional-first language.

Further links

There is lots of other news relevant to Visual Studio F# developers, today.  Check out some of these links:

• Soma’s blog
• Highlights of today’s VS 2015 news, including the free Visual Studio Community Edition, which supports F# and extensions like the Visual F# Power Tools
• C#/VB team blog
• Links to content covering new developments in those “other” .NET languages
• Visual Studio Connect
• Live stream/recording of presentations covering VS 2015 announcements
• Visual F# will be represented at the Day 2 Managed Languages panel – tune in!

Enough talk, let’s look at what’s new for F#!

New Language Capabilities

Constructors as first-class functions

As a functional-first language, F# has always provided rich support for processing and manipulating function values, both curried-style functions and traditional .NET methods.  One longstanding gap in that support was for constructors – there was no way to treat a type constructor as an isolated function that could be passed around and composed with other functions.  This limitation was one of the few sources of boilerplate in F# code, mandating the use of small lambda functions in order to invoke constructors.

This is now resolved – constructors are now treated as first-class functions, with the same treatment as other traditional .NET methods.

So, as an example, instead of writing this:

You can now write this:

Simplified use of mutable values

Mutable values are permitted in F#, though immutability is the default.  In the past, the ‘mutable’ keyword was used to designate a stack-based mutable value, and that value could be mutated using the <- operator.  If the mutable value happened to be captured by a closure and a heap-based value was required, the ‘ref’ syntax was needed instead, and mutation was done via the := operator.

These distinct syntaxes led to some code inelegance and developer confusion, as it was often difficult to reason ahead of time about which approach was going to be required.

With F# 4.0, developers can now just use the ‘mutable’ keyword for all mutable values, and the compiler will take care of the rest, creating a stack-based value if possible, otherwise implicitly converting to a ref cell.

So whereas you previously needed a ‘ref’ value for ‘total’ here:

You can now use ‘mutable’ and it “just works”:

Advanced users who prefer to have explicit knowledge of the stack/heap semantics can enable warning 3180 (--warnon:3180 for fsc.exe or fsi.exe) and will be notified when a ‘mutable’ declaration has been implicitly converted to ‘ref’.

Support for high-dimensional arrays

The .NET framework supports up to 32-dimensional arrays, but in the past F# only supported use of up to rank-4 arrays.  Not only were arrays of rank 5+ not possible to create and manipulate from F# code, the compiler could sometimes fail to consume external libraries which relied on high-dimensional arrays.

This is now fixed.  Although there is not yet support for creating and manipulating high-rank arrays, the compiler will now properly handle these types up to rank-32.

Support for static parameters to provided methods

F# type providers were previously limited to accepting static parameters only on the top-level provided type. From there, all other provided types, methods, and properties needed to be generated based on this single set of parameters.

With F# 4.0, the type provider mechanism has been expanded to allow for static parameters on provided methods, as well.

With this change, instead of requiring users to declare multiple top-level types, each with distinct parameters, there is now an option to use a single type declaration along with parameterized usage of methods.  For certain kinds of type providers, this can greatly streamline the developer experience.

A simple example is a provided “safe string” type which enforces that the number of slots in a String.Format format string matches the number of arguments passed.  This can now be done with a single type declaration, and a parameterized Format method:

Slicing syntax support for F# lists

F# linked lists now support the familiar “slicing” syntax, long present for arrays, for reading elements and creating sub-lists.

Simplified usage of units of measure with printf-family functions

printf-family functions previously required developers to explicitly strip off any measure information before values could be formatted.

This requirement has been relaxed – values with measure information are now handled seamlessly.

Modified GC settings on the compiler for better performance

Not a language feature, but surely of interest to F# language developers, is a change to the GC mode used by the F# compiler.  fsc.exe now uses GCLatencyMode.Batch, which gives a noticeable improvement in overall throughput, something that any F# developer will welcome.

Our testing indicates that this setting alone can provide upwards of 10% better compile performance. Click the chart below for a full-size plot of the performance data.

Enhancements to the FSharp.Core runtime

Normalized collections modules

The three collection types used most frequently in F# code are Array, List, and Seq.  Each of these types has a dedicated module containing various higher-order processing functions.  These functions are probably familiar to any functional programmer or LINQ user – map, fold, iter, etc.

In the past, these functions were not all uniformly available across the collection types. For example, the ‘distinct’ function was present for Seq, but missing for Array and List. The ‘tail’ function was present for List, but not for Array or Seq.

To work around these gaps in the API, developers would often need to convert their collections from one type to another, and back, just to take advantage of a particular function. This often led to inelegant and inefficient code.

In F# 4.0, the collections API has been fully normalized across Array, List, and Seq.  There are now dedicated, optimized implementations of all common operations for each type, and even a few brand-new functions.  This represents the addition of a whopping 95 APIs in total.

The chart below shows the new APIs (green), previously-existing APIs (blue), and intentional remaining gaps (white). Click for full size.

Faster generic comparison

The internal tables of optimized hash-comparison implementations used by F# code have been expanded and improved, leading to significant performance gains when processing primitive types such as int, string, and so on.

Performance improvements of 5x or more can be found in F# 4.0 when using APIs such as {List/Array/Seq}.{distinct/distinctBy/groupBy} which rely heavily on these comparisons.

Better async stack traces

Exceptions occurring in F# async code now have their stack traces preserved in a more user-friendly way, namely the top frame should now always point to the proper origin of the exception.

For code like this:

The top frames of the stack trace were previously rather opaque:

System.Exception: Boom
   at <StartupCode$FSharp-Core>.$Control.StartImmediate@1471-1.Invoke(Exception exn)
    at Microsoft.FSharp.Control.CancellationTokenOps.StartWithContinuations@1230-1.Invoke(Exception x)

But now point directly to the relevant code:

System.Exception: Boom
   at FSI_0011.f1@1-3.Invoke(Unit unitVar) in Script.fsx:line 1
   at Microsoft.FSharp.Control.AsyncBuilderImpl.callA@849.Invoke(AsyncParams`1 args)
   --- End of stack trace from previous location where exception was thrown ---

Assorted small performance improvements

A variety of small performance optimizations have been made across the runtime and compiler, making progress toward longer-term goals of faster compile time and a highly-optimized FSharp.Core runtime.

VS tooling improvements

Assembly metadata in project templates

All of the in-box F# project templates have been updated to now include an AssemblyInfo.fs file, containing default values for various assembly-level attributes like AssemblyVersion, AssemblyTitle, etc.  This aligns F# project templates better with those of other languages (e.g. C#), where such files have long been used.

Improved startup time for FSI

In F# 3.1.2, support was added for using non-locking shadow copy when referencing DLLs in F# Interactive.  One downside of enabling this feature was that it caused fsi.exe to be noticeably slower on startup.

This issue is now largely resolved, after adjusting the AppDomain loading behavior for the process.

New hotkeys for FSI

From within Visual Studio, hotkeys are now assigned for the “Reset” and “Clear All” actions of F# Interactive.  “Reset” is now mapped to Ctrl+Alt+R, and “Clear All” is now mapped to “Ctrl+Alt+C”.  These mappings were chosen to match those found in other F# IDEs.

Feedback

We are excited for users to start dogfooding Visual F# 4.0 and VS 2015.  Please log any issues on our Codeplex page: https://visualfsharp.codeplex.com/WorkItem/Create

Enjoy!

Building upon Visual F# 3.1, and the first out-of-band update Visual F# Tools 3.1.1, Visual F# Tools 3.1.2 is a standalone, F#-only installer that packages the latest updates to the F# compiler, interactive, runtime, and Visual Studio integration.  The IDE updates apply to Visual Studio 2013 Pro+, Desktop Express, and Web Express.

A release by and for the F# community

To begin with, it’s worth noting that this is the first Visual F# Tools release since we expanded our open source efforts and began taking contributions, and therefore the first release to include direct contributions from the F# community! We would like to thank all of the developers who worked with us by opening bugs, sending pull requests, and participating in discussions.

Commits from the following community F# developers are included in Visual F# Tools 3.1.2: antofik, Don Syme, Jon Harrop, Robert Jeppesen, Steffen Forkmann, Vladimir Matveev, Will Smith, Xiang Zhang.

What’s new?

Expanded portable library support, including Windows Phone 8.1

We continue to expand .NET portable library support in Visual F#.  New in this release, developers will find F# project templates, along with compiler and runtime support, for two additional portable profiles:

• Profile 78 (.NET Framework 4.5, Windows 8, Windows Phone Silverlight 8)
• Profile 259 (.NET Framework 4.5, Silverlight 5, Windows 8, Windows Phone 8.1)

This is in addition to the two profiles previously supported – Profile 47 (.NET Framework 4.5, Silverlight 5, Windows 8) and Profile 7 (.NET Framework 4.5, Windows 8).

Issues with adding project references between C# and F# portable libraries have also been addressed in this release. Altogether, this means that for the first time you can add an F# portable library project directly to a Windows Phone 8.1 solution!

Non-locking assembly references in FSI

F# developers love the quick-iteration development workflow enabled by F# Interactive – “edit-compile-test” is more or less distilled to “edit-test” – and tend to dislike anything that slows them down.

Oddly enough, one of the most common speed bumps in this loop is actually F# Interactive itself! Adding a #r assembly reference causes the referenced assembly to be locked on disk. If that assembly is part of your solution, and you want to rebuild it, make sure to restart FSI first!  If you don’t, your build will fail with the dreaded “The process cannot access the file 'bin\Debug\ClassLibrary1.dll' because it is being used by another process.”

Those errors should no longer be an issue. F# Interactive now supports non-locking #r references via shadow copy.

This is a configurable behavior.  Non-locking references are enabled by default in the hosted Visual Studio F# Interactive, and configurable via the F# Interactive options dialog. On the command line, the default behavior for fsi.exe has not been changed, but you can easily enable the new behavior via the switch --shadowcopyreferences+

Support for Publish in web and Azure projects

If you are using F# for web development, perhaps utilizing one of the excellent community project templates that are available, you have likely noticed that the Visual Studio “Publish” action has not worked for F# projects in the past.  This long-standing issue has finally been addressed; you can now publish F# web and Azure projects directly from Visual Studio!

Minor language changes

Improved *nix compatibility with #! in F# scripts

The F# compiler now allows for the shebang (#!) directive to exist at the beginning of F# source files, and will treat such a line as a comment.  This allows F# scripts to be compatible with the Unix convention whereby a script can indicate to the OS what interpreter to use by providing the path to that interpreter on the first line, following the #! directive.

This change does not affect how F# file associations are configured on Windows.

Compiler support for high-dimensional slicing

F# supports slicing syntax for working with arrays and other multi-dimensional data types, and developers can define custom slicing behavior for their own types by implementing appropriate overloads of the GetSlice and SetSlice methods.

In previous releases, the compiler enforced a limit of 4 slicing dimensions.  This limit has been lifted; developers are now free to define arbitrary-dimensional slicing semantics in their code.

Spaces in active pattern case identifiers

There was previously a restriction preventing space characters from being used in active pattern case identifiers.  This restriction has been relaxed; space characters may now be used in ``  ``-escaped case identifiers.

And beyond

In addition to what’s mentioned here, Visual F# 3.1.2 also includes a number of bug fixes, a couple of performance improvements, and even some optimized code generation for struct processing. A full list of changes and bug fixes is in our Codeplex repo.

More Information

For more information about F# generally, please visit https://fsharp.org. If you are interested in contributing to the Visual F# Tools, please visit our open source home at https://visualfsharp.codeplex.com/