From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA18390; Mon, 10 Jun 2002 16:04:37 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id QAA18393 for ; Mon, 10 Jun 2002 16:04:36 +0200 (MET DST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g5AE4Zb19977; Mon, 10 Jun 2002 16:04:35 +0200 (MET DST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 10 Jun 2002 07:04:34 -0700 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 10 Jun 2002 07:04:33 -0700 Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 10 Jun 2002 07:04:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Caml-list] F# Date: Mon, 10 Jun 2002 07:04:33 -0700 Message-ID: Thread-Topic: [Caml-list] F# Thread-Index: AcIP3oyCAl22s09TTuGmZwk5f9nxhgApX8qg From: "Don Syme" To: "Chris Hecker" , "Xavier Leroy" , "Vincent Foley" Cc: X-OriginalArrivalTime: 10 Jun 2002 14:04:33.0859 (UTC) FILETIME=[BF75C130:01C21087] Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk [ 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=20 > >values of variable (i.e. 'a) type. This is simple erasure. >=20 > Huh. I must not understand the issues, because I thought it was harder=20 > than this. If you can just make 'a into objects, why were people=20 > complaining that it's hard to make it work? (Xavier called your work a=20 > tour de force, and I thought I'd learn something by trying to understand=20 > why. But, I'm a relative beginner, and the research papers dive in deep=20 > 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).=20 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. =20 > Also, what are the dlls that are installed? When you say "compiled for V1=20 > of the CLR", does that mean you have a bytecode file that will run anywhere=20 > (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=20 > 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.=20 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