RE: [Caml-list] F#

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

[ 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