RE: [Caml-list] C# 3.0 enhancements (in re: F#)

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

Hi Bill,

> Does anyone have a sense of the extent to which F# is (could be) a
> viable entry in the .NET arena, as opposed to an entertaining
exercise?

Normally I do not mail to the Caml-list about F#, since such mails can
easily be misinterpreted.  However, since the topic came up as an
explicit question I thought I would mention that more information about
F# can be found via Google ("F#"), or at

http://research.microsoft.com/projects/fsharp

though more fun is my blog at 

http://blogs.msdn.com/dsyme

F# can cross-compile large Caml applications, e.g. the Static Driver
Verifier (50K lines -
http://www.microsoft.com/whdc/devtools/tools/SDV.mspx) and the SPiM
stochastic Pi calculus simulator (http://www.doc.ic.ac.uk/~anp/spim/),
the Abstract IL libraries and the F# compiler itself.  We take
compatibility with the shared core language of OCaml very seriously, to
the extent that if our implementation of a library function throws a
different exception to the OCaml implementation we regard that as a bug.
We want to make sure that cross-compilation between F# and OCaml remains
a valid compilation model.   However, we do not aim to implement all
OCaml language features - the OCaml team are too quick to add
interesting (and useful) typing features to make that possible.
Furthermore many do not make sense in the context of a .NET programming
language.

At some point I would dearly like to take the opportunity to write an
extensive report on F# for the benefit of the OCaml community.  Although
F# is a simpler language than OCaml, it's role as a .NET language places
it alongside many current interesting developments in programming, e.g.
software-isolated process (called AppDomains in .NET)  the recently
announced LINQ project (mentioned below), server-side programming using
ASP.NET or the ability to host semi-trusted code inside SQL Server.  In
my opinion this leads to a substantially different perspective on
language design and development, and indeed the whole architecture of
the software environment feels substantially different.  I think one
role that F# plays for the OCaml community is to give a chance for
people in the OCaml world dip into this architecture without relearning
everything.  And, if you ever find yourself desperate to talk to some
.NET libraries, you may find it feasible to use F# for this purpose.

Anyway, that's my F# post for the year :-)   If you do take it for a
spin then please let us know how you get on.

Don Syme
Microsoft Research,
Cambridge





-----Original Message-----
From: caml-list-bounces@yquem.inria.fr
[mailto:caml-list-bounces@yquem.inria.fr] On Behalf Of Bill Wood
Sent: 18 September 2005 22:08
To: Evans, Jeffrey (IT)
Cc: caml-list@inria.fr
Subject: RE: [Caml-list] C# 3.0 enhancements (in re: F#)

   . . .
> >It may interest people to know that C# is to add inferred types,
> >lambda expressions with limited type inference, some other functional
> >features.  Unfortunately the only reference is a M$ Word document(!),
> >but it's interesting reading nevertheless:
> >
> >http://msdn.microsoft.com/vcsharp/future/default.aspx
> >
> >Rich.
> 
> 
> For that matter, F# has been around on the .NET platform for a little
> while now.

Does anyone have a sense of the extent to which F# is (could be) a
viable entry in the .NET arena, as opposed to an entertaining exercise?

 -- Bill Wood


_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs