F# Discoveries This Week 11/22/2009

RickM — Sun, 22 Nov 2009 23:49:52 GMT

Over this past week at PDC I was lucky enough to see some fantastic sessions and spend time with members of the F# and greater Visual Studio language teams. Naturally, these experiences have left me both floored and swimming in new ideas. This edition of Discoveries This Week includes both the very best of what I saw at PDC 2009 and the most outstanding things I’ve glimpsed going on in the F# community. Please do enjoy.

Reflection on the PDC Keynotes

For the most information in the shortest amount of time I suggest watching the day one and day two PDC keynotes. They are both jam packed with exciting announcements and demos. While at PDC I wrote about my experience watching these here (day one) and here (day two).

Microsoft Perspectives on the Future of Programming

Come hear from several of the Microsoft senior technical leaders about the future of programming, programming languages, and tools.

If you watch just one PDC session let this be it.

With Butler Lampson, Erik Meijer, Don Box, Jeffrey Snover, Herb Sutter, and Burton Smith, Microsoft’s best gathered to debate the future of programming in a twitter driven panel at PDC. I was happy to be able to contribute with a question on type systems which erupted into quite a disagreement. I will be writing about this session at length, and reflecting on my past thoughts about this topic, in the near future.

Luke Hoban’s F# for Parallel and Asynchronous Programming

F#, a functional and object-oriented language for Microsoft .NET, adds many tools to make parallel and asynchronous programming both fun and easy. Come hear the core concepts of the F# language, and see how ideas like immutability, functional design, async workflows, agents, and more can be used to meet the challenges of today’s real-world applications.

By combining small, easily understood, ideas Luke constructs F#’s big picture in the most engaging way I’ve seen to date. This is now my go to talk for people who are interested in, but new to, the F# programming language.

Jomo Fisher’s F# Scripting, .NET 4.0 and Mixed-mode assemblies

One of the recent problems we’ve seen is that, because of the support for side-by-side runtimes, .NET 4.0 has changed the way that it binds to older mixed-mode assemblies. These assemblies are, for example, those that are compiled from C++\CLI. Currently available DirectX assemblies are mixed mode.

This clever approach to switching the F# REPL to 2.0 binding mode is particularly handy to know.

Matthew Moloney’s Collaborative Development Using F# Interactive

This is a proof of concept of an interactive collaborative development environment I built using F# Interactive. The aim here is to explore different ideas for further development, not so much as to present an alternative to Visual Studio.

I couldn’t pass this very cool idea up. I can’t help but think about extending this to full feldged explorative programming community websites.

Bart Czernicki’s Silverlight 3 and F# Support in Visual Studio 2010

The goal of this blog post is to make you aware of F# support in Silverlight in Visual Studio 2010. In addition, this blog post shows an example why F# is going to be very important for Silverlight architects and developers. Note: This is NOT an intro to F#.

A great post. I am always interested in seeing concrete examples of F# adding value to existing technologies and platforms. I have a sneaking suspicion that there are very few places where it won’t.

One of these languages is not like the others - Part 1 - Enforcement of Abstract Implementation

RickM — Tue, 10 Feb 2009 15:47:00 GMT

This is the first in a series of posts on the topic of interaction between different .NET languages. I will cover all of the major Microsoft languages: C#, Visual Basic, F# and C++/CLI.

In this first post in the series I will build a four language project in Visual Studio 2008 and begin to explore inter-language inheritance. One of the languages behaves in a significantly different way when compared with the others, can you guess which one it is?

Enforcement of Abstract Implementation

First things first, let’s define our abstract base class. C# is considered the standard language for library architecting and so it is what we will be using.

  1: public abstract class CSharpBaseClass
  2: {
  3:   public abstract void PublicAbstractMethod();      
  4:   public abstract void PublicAbstractMethod(int inint);
  5:   protected abstract void ProtectedAbstractMethod();
  6:   protected abstract void ProtectedAbstractMethod(int inint);
  7: }

In each of our child projects we will be inheriting from this class. Let’s start with C#.

  1: public class CSharpChildClass : CSharpBaseClass
  2: {
  3: }

Now anyone with even a bit of experience in the C# language knows that this won’t compile. For each of the abstract methods in the base class the inheriting class is expected to provide an implementation.

… error CS0534: 'CSharpChild.CSharpChildClass' does not implement inherited abstract member …

This is similarly true for Visual Basic.

  1: Public Class VBChildClass

  2:   Inherits CSharpBase.CSharpBaseClass

  3: End Class

… error BC30610: Class 'VBChildClass' must either be declared 'MustInherit' or override the following inherited 'MustOverride' member(s):

F# shares this behavior as well.

  1: type FSharpChildClass() =
  2:   inherit CSharpBase.CSharpBaseClass()

… error FS0191: No implementation was given for 'CSharpBaseClass.PublicAbstractMethod() : unit'.

Kudos to the F# compiler designers for the verbose compile time errors.

error FS0054: This type is 'abstract' since some abstract members have not been given an implementation. If this is intentional then add the '[<AbstractClass>]' attribute to your type.

However, C++/CLI does not. It’s perfectly acceptable to inherit from an abstract class and provide no implementation for it’s abstract members.

  1: public ref class CppChildClass : public CSharpBaseClass
  2: {
  3: };

While a warning is issued, it seems insufficient for what has just taken place:

… warning C4570: 'CppChild::CppChildClass' : is not explicitly declared as abstract but has abstract functions

The result is that the class in question is defaulted to abstract. If someone where to attempt to instantiate it downstream, it would cause a compiler error:

  1: CppChildClass cpp = new CppChildClass();
  2: cpp.LocalMethod();

error CS0144: Cannot create an instance of the abstract class or interface 'ManagedCppChild.ManagedCppChildClass'

This is bad because, if you were an API developer and so did not consume all of your objects, it would be possible to ship a version of your product with abstract suddenly toggled on for one or more of your classes. All it would take would be for a developer to add a new inherited class or member to an existing abstract base class without writing a corresponding test for every abstract member or inheriting class.

Conclusion

So, what can we learn from this? It seem that when using C++/CLI (or managed C++) it is not sufficient to depend on abstract classes to enforce that members are implemented. Testing must also be strictly enforced.

Rick Minerich's Development Wonderland : VB.NET, languages