<?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="2003/01/881a04377ca8cc96189abbe6f03f111a"
  from="Nicolas Cannasse &lt;warplayer@f...&gt;"
  author="Nicolas Cannasse"
  date="2003-01-14T03:34:45"
  subject="Re: [Caml-list] unboxing of unary datatypes"
  prev="2003/01/139e0e1f8dac72a55d31aabe8e5f20ce"
  next="2003/01/88a260e9ef06cf00d42b81f78abfe86d"
  prev-in-thread="2003/01/0dd0b46584a7a0b466d9c2f5820331a4"
  next-in-thread="2003/01/b90d9c8752fc9867bb56d0b5f1caabd5"
  prev-thread="2003/01/047f0a828ed5d8eab79372879e151577"
  next-thread="2003/01/6b3b8aa926b31df45c1942e68097615c"
  root="../../"
  period="month"
  listname="caml-list"
  title="Archives of the Caml mailing list">

<thread subject="[Caml-list] unboxing of unary datatypes">
<msg 
  url="2003/01/0dd0b46584a7a0b466d9c2f5820331a4"
  from="Hal Daume III &lt;hdaume@I...&gt;"
  author="Hal Daume III"
  date="2003-01-14T00:08:37"
  subject="[Caml-list] unboxing of unary datatypes">
<msg 
  url="2003/01/881a04377ca8cc96189abbe6f03f111a"
  from="Nicolas Cannasse &lt;warplayer@f...&gt;"
  author="Nicolas Cannasse"
  date="2003-01-14T03:34:45"
  subject="Re: [Caml-list] unboxing of unary datatypes">
<msg 
  url="2003/01/b90d9c8752fc9867bb56d0b5f1caabd5"
  from="Florian Hars &lt;hars@b...&gt;"
  author="Florian Hars"
  date="2003-01-14T11:17:38"
  subject="Re: [Caml-list] unboxing of unary datatypes">
<msg 
  url="2003/01/199c38bda63ce2bfd088760b81c5d032"
  from="Nicolas Cannasse &lt;warplayer@f...&gt;"
  author="Nicolas Cannasse"
  date="2003-01-14T14:12:31"
  subject="Re: [Caml-list] unboxing of unary datatypes">
</msg>
</msg>
</msg>
<msg 
  url="2003/01/88a260e9ef06cf00d42b81f78abfe86d"
  from="Fabrice Le Fessant &lt;fabrice@l...&gt;"
  author="Fabrice Le Fessant"
  date="2003-01-14T10:53:50"
  subject="Re: [Caml-list] unboxing of unary datatypes">
<msg 
  url="2003/01/d0f4e551ba89f8f7b4b9cfad3f89e3df"
  from="Christophe Raffalli &lt;Christophe.Raffalli@u...&gt;"
  author="Christophe Raffalli"
  date="2003-01-14T18:38:09"
  subject="Re: [Caml-list] unboxing of unary datatypes">
</msg>
</msg>
</msg>
</thread>

<contents>
&gt; Hi all,
&gt;
&gt; I originally had a very calculation intensive program which used a data
&gt; type which looked like:
&gt;
&gt; &gt; type foo = Foo of float
&gt;
&gt; I could just have easily used floats, but I wanted to ensure that I didn't
&gt; do anything stupid (like try to multiply a foo by a float), so I did this
&gt; boxing so the type-checker would help me out.

Hi,

What you might need here are shadow types.
You can define in your ML source file:

type foo = float
let mfoo f f' = f *. f' (* or better let mfoo = ( *. ) *)

and in your interface ( MLI file ) :

type foo
val mfoo : foo -&gt; foo -&gt; foo

then, other modules trying to work with your foo will have to use your set
of operators because they won't know what exactly is "foo".

&gt; Can someone explain this to me?  Why doesn't the compiler optimize out the
&gt; constructor?

Because they don't have the same C raw representation.
There is one more indirection when you use a constructor.
If you want to interface OCaml with C, you have to be sure that the compiler
won't try to optimize things in an incompatible way ( that goes for all
compilers I think... )

Nicolas Cannasse

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

