<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE message PUBLIC
  "-//MLarc//DTD MLarc output files//EN"
  "../../mlarc.dtd"[
  <!ATTLIST message
    listname CDATA #REQUIRED
    title CDATA #REQUIRED
  >
]>

  <?xml-stylesheet href="../../mlarc.xsl" type="text/xsl"?>


<message 
  url="2002/07/d05ae36b4009e6467ab13a7926deac7c"
  from="Andrew Kennedy &lt;akenn@m...&gt;"
  author="Andrew Kennedy"
  date="2002-07-26T04:33:34"
  subject="RE: [Caml-list] ocaml for Mono/.NET?"
  prev="2002/07/3a3fcdeb0903a486a8e51b5dbe0882df"
  next="2002/07/931a2b1570d2337011ffbde0d42f8498"
  prev-thread="2002/07/1b763a0b53af91c54f488c8dd7c4ed9a"
  next-thread="2002/07/931a2b1570d2337011ffbde0d42f8498"
  root="../../"
  period="month"
  listname="caml-list"
  title="Archives of the Caml mailing list">

<thread subject="RE: [Caml-list] ocaml for Mono/.NET?">
<msg 
  url="2002/07/d05ae36b4009e6467ab13a7926deac7c"
  from="Andrew Kennedy &lt;akenn@m...&gt;"
  author="Andrew Kennedy"
  date="2002-07-26T04:33:34"
  subject="RE: [Caml-list] ocaml for Mono/.NET?">
</msg>
</thread>

<contents>
Our SML.NET implementation compiles the functors of Standard ML by
expanding them at compile-time.

There *is* a tension between supporting all the features of the source
language and at the same time providing smooth inter-operation with
other .NET languages. Hopefully for functional languages this tension
will lessen when parametric polymorphism is supported by the .NET CLR. 

- Andrew.

-----Original Message-----
From: Michael Vanier [mailto:mvanier@cs.caltech.edu] 
Sent: 21 July 2002 00:27
To: bemann@execpc.com
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] ocaml for Mono/.NET?


&gt; Date: Sun, 21 Jul 2002 00:25:49 -0400
&gt; From: Travis Bemann &lt;bemann@execpc.com&gt;
&gt; 
&gt; On Wed, Jul 17, 2002 at 12:31:52AM -0700, Michael Vanier wrote:
&gt; &gt;
&gt; &gt; Are there any plans to port ocaml to .NET?  Given that the Mono
&gt; &gt; implementation of .NET is coming along nicely, having an ocaml
compiler
&gt; &gt; that can compile to .NET IL would greatly increase ocaml's
visibility, not
&gt; &gt; to mention solving some of the library and packaging issues that
keep
&gt; &gt; coming up with ocaml.  I know about the F# project, but that
implementati=
&gt; on
&gt; &gt; appears to be only for a subset of ocaml, and is controlled by
Microsoft.
&gt; &gt; I'd be happier with something from the core ocaml team.  Of course,
MY
&gt; &gt; motivation is that I'd like to be able to write nifty graphical apps
in
&gt; &gt; ocaml under Linux.  After all, once you learn ocaml, C# is not
really very
&gt; &gt; tempting ;-)
&gt; 
&gt; The thing is that this subset is FORCED by the inherent design of the
&gt; CLR/.NET bytecode virtual machine, which doesn't support stuff like
&gt; parameterized modules.  Any attempt to port something like OCaml to
&gt; something like CLR/.NET will only result in its bastardization, and
&gt; thus the loss of many of its features/advantages.
&gt; 

That's interesting, considering that standard ML is one of the languages
supposedly targeted by the common language runtime (by which I mean that
the SML team was consulted on what features they would need in the
intermediate language in order to support SML).  Doesn't SML have
parameterized modules?

Mike
-------------------
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
-------------------
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

</contents>

</message>

