RE: [Caml-list] F#

["Don Syme" <dsyme@microsoft.com>]

> I was under the impression that the CLR as it's currently shipped could not
> do parametric polymorphism.  [Xavier's post from last year listing what
> isn't supported is here:  http://caml.inria.fr/archives/200102/msg00190.html]

F# programs compiled for V1 of the CLR use the type "object" for all values of variable (i.e. 'a) type.  This is simple erasure.  It is an OK way to implement PP (it's how GJ does it) - there are a few problems, e.g. type distinctions get lost in the IL so interop is not quite how you might want it, and it's not the model we ultimately wanted for C# because of performance and runtime-type reasons (we would like an object's full type to be visible at runtime, e.g. for reflection, just as it is for array types for the JVM and CLR).  

Probably the most irritating thing about using erasure for F# is that it forces the treatment of arrays to be slightly non-uniform.  F#-when-compiling-for-V1-of-the-CLR supports two families of array types: truly parametric arrays of the form "'a array"  and a family of .NET array types "'a[]".  In the former  are always compiled as "object[]", hence, for example, byte arrays won't have the representation you might expect.  In the latter 'a is effectively a weak type variable and must always be known at compile time, i.e. you can't generalize over variables used in _[] types.  The former are for polymorphic programming over arrays where you don't care about interop (e.g. when you're writing new data structures like hash tables built using arrays).  The latter are for when you need to build or access components that transact .NET array types (i.e. int[] in F# is guaranteed to be identical to C#'s int[] type).  F# supports the latter by inlining all code that manipulates _[] types.  It strikes me that it's possible that GJ could have made this distinction as well (as far as I know you can't currently write any code in GJ that polymorphically manipulates array types, e.g. creates new arrays - they could have allowed this but forced all source-language compilers to inline all such code).

> PS.  Why F#?  The last thing we need are more symbolic characters in our
> language names!  :)  What was wrong with caml.net, just the compatibility
> issues?

I concluded that it wasn't really appropriate for Microsoft Rsearch to release anything with the name "Caml" in it - that is up to the INRIA team.  Also the language isn't exactly OCaml or Caml-light, especially because of immutable strings, as well as the extensions like the one above.  As for F#, well it gave the /. crowd a good chance to crack some pretty good jokes, the best of which was "F# is a Forth above C#"... :-).  Another pointed out how easily "F#" becomes "F#!@"...