caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* [Caml-list] F#
@ 2002-06-08 15:05 Vincent Foley
  2002-06-08 16:01 ` Xavier Leroy
  0 siblings, 1 reply; 14+ messages in thread
From: Vincent Foley @ 2002-06-08 15:05 UTC (permalink / raw)
  To: OCaml Mailing list

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

F# is a .NET language based on the core of OCaml.  It can use the .NET
libraries and interact with C#.  What do you guys think?

Vincent

-- 

Vincent Foley-Bourgon
Email: vinfoley@iquebec.com
Homepage: http://darkhost.mine.nu:81
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


^ permalink raw reply	[flat|nested] 14+ messages in thread
* RE: [Caml-list] F#
@ 2002-06-08 23:04 Don Syme
  0 siblings, 0 replies; 14+ messages in thread
From: Don Syme @ 2002-06-08 23:04 UTC (permalink / raw)
  To: Xavier Leroy, Vincent Foley; +Cc: OCaml Mailing list

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2330 bytes --]

And I'm even more grateful to Xavier and the team for doing such a great job with OCaml over the years, and for providing a solid core language, an excellent runtime system and the very interesting set of langauge features they've added to the core.  Core Caml provides a great starting point for work of all kinds: I used it in my PhD thesis, for example, as the term language for a theorem prover.
 
I chose to implement a core Caml compiler for .NET partly to test out generics, but also because I want to be able to program against .NET libraries using the language I love to program in, and reuse the libraries and techniques I've developed.  I guess it's possible I'll get a bit of flak from the Caml community about F#.  Being at Microsoft Research I presume I'll be writing a fair bit of .NET code sooner or late, and personally I'd rather do that in Caml/F# than C#... I hope the Caml community won't mind me making that opportunity available to others via the public release of F#.
 
Cheers,
Don
 

	-----Original Message----- 
	From: Xavier Leroy [mailto:xavier.leroy@inria.fr] 
	Sent: Sat 08.06.2002 18:01 
	To: Vincent Foley 
	Cc: OCaml Mailing list 
	Subject: Re: [Caml-list] F#
	
	

	> http://research.microsoft.com/projects/ilx/fsharp.htm
	>
	> F# is a .NET language based on the core of OCaml.  It can use the .NET
	> libraries and interact with C#.  What do you guys think?
	
	I think that Don Syme and his Microsoft Cambridge colleagues did a
	great job with adding parametric polymorphism to the .NET framework --
	something that was initially overlooked in .NET --, and I'm very happy
	that they chose core Caml to demonstrate this extension in action.
	
	By the way, for those of you who are in the Paris area: Don Syme will
	give a talk on F# at INRIA Rocquencourt on the morning of June 14th,
	and everyone is welcome to attend.  E-mail me privately for more info.
	
	- Xavier Leroy
	-------------------
	To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
	Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
	Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
	

N‹§²æìr¸›zf¢•Æ¦–X¬¶·ª¹ë-ŠzâiúÀ­Èb½ë!¶Ú\x7fýƦ–)뉧ë\x06è+zš+¶Èm¶Ÿÿq©¥Šzâiúÿn)ÿq©¥nè,\x14\x04!¶Ú\x7fýƦ–)뉧ëüP\x10ü\x17 ŠyÞ®Éb²Øm¶Ÿÿ‚º.¦Ìš†Š\x1c¢o஋©þ‡\x1ašVÞ‚)çz»

^ permalink raw reply	[flat|nested] 14+ messages in thread
[parent not found: <BCDB2C3F59F5744EBE37C715D66E779C0481E206@red-msg-04.redmon d.corp.microsoft.com>]
* RE: [Caml-list] F#
@ 2002-06-09 12:26 Don Syme
  2002-06-10  6:22 ` Michael Vanier
  0 siblings, 1 reply; 14+ messages in thread
From: Don Syme @ 2002-06-09 12:26 UTC (permalink / raw)
  To: Chris Hecker, Xavier Leroy, Vincent Foley; +Cc: OCaml Mailing list


> 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#!@"...

 


 


^ permalink raw reply	[flat|nested] 14+ messages in thread
[parent not found: <BCDB2C3F59F5744EBE37C715D66E779C0481E208@red-msg-04.redmon d.corp.microsoft.com>]
* RE: [Caml-list] F#
@ 2002-06-10 14:04 Don Syme
  0 siblings, 0 replies; 14+ messages in thread
From: Don Syme @ 2002-06-10 14:04 UTC (permalink / raw)
  To: Chris Hecker, Xavier Leroy, Vincent Foley; +Cc: fsharp


[ Chris - I've moved this to the F# discussion list, bcc'd to caml-list.
I don't want to clog caml-list with F#-specific discussions.... :-) ]

> >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.
> 
> Huh.  I must not understand the issues, because I thought it was
harder 
> than this.  If you can just make 'a into objects, why were people 
> complaining that it's hard to make it work?  (Xavier called your work
a 
> tour de force, and I thought I'd learn something by trying to
understand 
> why.  But, I'm a relative beginner, and the research papers dive in
deep 
> pretty quick.  :)

Compiling to object works for ML because it has no runtime type
information, but you run into problems like those described in the last
email.  It is also less efficient in some circumstances than direct
support for PP in a virtual machine (an array of objects is more
expensive than an array of integers for example). 

Hence we have been adding support for PP directly to the CLR and the
intermediary language of the CLR.   It was this work Xavier was
referring to.  See http://research.microsoft.com/projects/clrgen for an
overview.  

> Also, what are the dlls that are installed?  When you say "compiled
for V1 
> of the CLR", does that mean you have a bytecode file that will run
anywhere 
> (like Java), or does it need the extension dlls to be installed?

There are a couple of small runtime DLLs.  These would need to be
installed in the same directory as your application if using F# for
server-side programming, or as part of your downloaded code if writing
client-side.  If I were to do web-site stuff with F# I would focus on
writing computational code in F# and using front-end builders in C# or
VB.  But I'll admit I haven't tried this out and it obviously depends on
your app.  You may be able to do the whole lot in F# if there isn't much
on the front end.  I'll give it a go and add a sample to the
distribution...

> Requiring people to install dlls is not quite as nice, but 
> still might be better than rewriting my app in java.

You would just have to make the DLLs part of your app, i.e. take a copy
of them and stuff them in the same directory as your .EXE.  The client
doesn't have to register them as a different package.  But please the
currently licence says you can only redistribute the DLLs for
non-commercial purposes - there may be flexibility in this if needed. 

I'd like to get rid of the DLLs to make this a little cleaner, and do
away with the legal hassles as well.  The DLLs only contain little type
definitions (pairs, tuples, lists, "ref", etc.) which get shared across
interoperating applications.   But if you are just writing small
applications then the types may as well get statically linked into your
application code, as you don't care about cross-language working in this
situation.  Static linking still offers a sensible deployment model,
especially when the "bulk" of the libraries (i.e. the .NET libraries)
get shared.

Cheers,
Don

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


^ permalink raw reply	[flat|nested] 14+ messages in thread
* Interactive technical computing
@ 2007-03-08  1:13 Jon Harrop
  2007-03-08  2:12 ` [Caml-list] " Erik de Castro Lopo
  0 siblings, 1 reply; 14+ messages in thread
From: Jon Harrop @ 2007-03-08  1:13 UTC (permalink / raw)
  To: caml-list


Being a user of both OCaml and Mathematica, playing with the new F# language 
from Microsoft and watching tutorial videos about VPython:

  http://showmedo.com/videos/series?name=pythonThompsonVPythonSeries

has given me a lot of inspiration about interactive technical computing 
environments. This class of applications is hugely useful for working 
scientists and engineers because it lets you slice and dice your data in 
interesting ways whilst also giving you visual throwback and even letting you 
do some fancy visualisations.

For example, I'm in the process of updating my ray tracer language comparison:

  http://www.ffconsultancy.com/languages/ray_tracer/index.html

and I'm using a mix of OCaml (to fire off compilation and execution commands) 
and Mathematica (to dissect the results, compute verbosity using regexps and 
plot graphs):

  http://www.ffconsultancy.com/tmp/mathematica.png

Mathematica's equivalent of the OCaml top-level is called a notebook. It 
provides expression input and result output, just like OCaml, but integrates 
graphics, adds typesetting and lots of mathematical functions. However, it is 
widely used for more general purpose programming despite being very slow.

Using F# from Visual Studio 2005 provides some of this functionality. The 
following screenshots illustrate 2D and 3D graphics spawned from an F# 
interactive session using a little of my own code and DirectX/ComponentsXtra:

  http://www.ffconsultancy.com/tmp/fs_xygraph.png
  http://www.ffconsultancy.com/tmp/fs_3dplot.png

For all non-trivials examples in F# it is necessary to spawn a separate thread 
to handle the GUI of the visualization, or the GUI will hang when the 
top-level is doing an intensive computation.

I think F# has a great future because of its ability to spawn visualizations 
from a running interactive session. Expensive commercial offerings like 
Matlab and Mathematica are ok when you're doing something they have built-in 
(e.g. a Fourier transform) but when you're problem is not trivially 
decomposed into their built-in operators (e.g. a wavelet transform), F# and 
OCaml are typically 2-5x faster, and when you must resort to more general 
purpose programming F# and OCaml are often 100x faster.

However, there is a lot of work to be done in getting competitive charting and 
visualization tools into F# and I'm thinking that OCaml could benefit from a 
joint venture here. Low-level routines would target DirectX in F# and OpenGL 
in OCaml but high-level routines could be language and platform agnostic, 
handling a scene graph that is essentially a typed version of Mathematica's 
to provide much faster graphics and even interactive visualisation 
(Mathematica is software rendered and not interactive!).

This raises several questions:

. What OCaml programs currently allow OpenGL-based visualizations to be 
spawned from the top-level?

. Has anyone tried to write an IDE that mixes OCaml code with graphics?

. Would anyone here be interested in a low-cost cross-platform technical 
computing environment based upon the OCaml and F# languages?

Obviously I'm interested in this from a commercial perspective. That looks 
easy for F# but not so easy for OCaml. Compiled OCaml+OpenGL code is not as 
portable (between machines) as F#+DirectX. Also, I can sell F# DLLs and even 
make the library available to other .NET languages (albeit with a 
significantly less productive API).

Finally, I'd like to note that operator overloading is probably the single 
biggest difference between my F# and OCaml code. The ability to apply + and - 
to many types, particularly vectors and matrices, makes this kind of work so 
much easier. Even if you have to add the odd type annotation. So I'd love to 
see a compatible implementation of overloading introduced into OCaml.

I'd like to hear everyone's opinions on this as, it seems to me, we're sitting 
on the foundations of a great technical computing system.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists


^ permalink raw reply	[flat|nested] 14+ messages in thread
* RE: [Caml-list] F#
@ 2007-03-08 14:41 Robert Fischer
  2007-03-08 15:10 ` Jon Harrop
  0 siblings, 1 reply; 14+ messages in thread
From: Robert Fischer @ 2007-03-08 14:41 UTC (permalink / raw)
  To: caml-list

> However, operator overloading (i.e. overloading symbols) makes numerical code 
> so much easier to read that it is worth sacrificing some inference for it.
>

Unless, of course, you like to know what it is you're actually doing.

It's bad enough trying to figure out what "+" means in an overloaded environment with nominal typing.  With duck typing, it's a mess, and it's a mess that both you and the compiler have to work hard to figure out.

I highly suggest checking out the Programmer-to-Programmer book on C# and their conversation about operator overloading.  They do a nice job documenting just why it's such a dangerous tool in the toolbox.

~~ Robert.


^ permalink raw reply	[flat|nested] 14+ messages in thread
end of thread, other threads:[~2007-03-08 23:07 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-06-08 15:05 [Caml-list] F# Vincent Foley
2002-06-08 16:01 ` Xavier Leroy
2002-06-08 23:04 Don Syme
     [not found] <BCDB2C3F59F5744EBE37C715D66E779C0481E206@red-msg-04.redmon d.corp.microsoft.com>
2002-06-09  1:30 ` Chris Hecker
2002-06-09 12:26 Don Syme
2002-06-10  6:22 ` Michael Vanier
     [not found] <BCDB2C3F59F5744EBE37C715D66E779C0481E208@red-msg-04.redmon d.corp.microsoft.com>
2002-06-09 17:49 ` Chris Hecker
2002-06-10 14:04 Don Syme
2007-03-08  1:13 Interactive technical computing Jon Harrop
2007-03-08  2:12 ` [Caml-list] " Erik de Castro Lopo
2007-03-08 12:41   ` [Caml-list] F# Jon Harrop
2007-03-08 14:41 Robert Fischer
2007-03-08 15:10 ` Jon Harrop
2007-03-08 17:30   ` Roland Zumkeller
2007-03-08 17:54     ` Brian Hurt
2007-03-08 23:07       ` skaller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).