HCoop / hcoop / debian / mlton.git / blame
? search:
summary | shortlog | log | commit | commitdiff | tree
blob | blame (incremental) | history | HEAD
Backport from sid to buster
[hcoop/debian/mlton.git] / doc / guide / localhost / OCaml
CommitLineData
7f918cf1
CE		 1<!DOCTYPE html>\r
2<html lang="en">\r
3<head>\r
4<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">\r
5<meta name="generator" content="AsciiDoc 8.6.9">\r
6<title>OCaml</title>\r
7<link rel="stylesheet" href="./asciidoc.css" type="text/css">\r
8<link rel="stylesheet" href="./pygments.css" type="text/css">\r
9\r
10\r
11<script type="text/javascript" src="./asciidoc.js"></script>\r
12<script type="text/javascript">\r
13/*<![CDATA[*/\r
14asciidoc.install();\r
15/*]]>*/\r
16</script>\r
17<link rel="stylesheet" href="./mlton.css" type="text/css">\r
18</head>\r
19<body class="article">\r
20<div id="banner">\r
21<div id="banner-home">\r
22<a href="./Home">MLton 20180207</a>\r
23</div>\r
24</div>\r
25<div id="header">\r
26<h1>OCaml</h1>\r
27</div>\r
28<div id="content">\r
29<div id="preamble">\r
30<div class="sectionbody">\r
31<div class="paragraph"><p><a href="http://caml.inria.fr/">OCaml</a> is a variant of <a href="ML">ML</a> and is similar to\r
32<a href="StandardML">Standard ML</a>.</p></div>\r
33</div>\r
34</div>\r
35<div class="sect1">\r
36<h2 id="_ocaml_and_sml">OCaml and SML</h2>\r
37<div class="sectionbody">\r
38<div class="paragraph"><p>Here&#8217;s a comparison of some aspects of the OCaml and SML languages.</p></div>\r
39<div class="ulist"><ul>\r
40<li>\r
41<p>\r
42Standard ML has a formal <a href="DefinitionOfStandardML">Definition</a>, while\r
43OCaml is specified by its lone implementation and informal\r
44documentation.\r
45</p>\r
46</li>\r
47<li>\r
48<p>\r
49Standard ML has a number of <a href="StandardMLImplementations">compilers</a>,\r
50while OCaml has only one.\r
51</p>\r
52</li>\r
53<li>\r
54<p>\r
55OCaml has built-in support for object-oriented programming, while\r
56Standard ML does not (however, see <a href="ObjectOrientedProgramming">ObjectOrientedProgramming</a>).\r
57</p>\r
58</li>\r
59<li>\r
60<p>\r
61Andreas Rossberg has a\r
62<a href="http://www.mpi-sws.org/%7Erossberg/sml-vs-ocaml.html">side-by-side\r
63comparison</a> of the syntax of SML and OCaml.\r
64</p>\r
65</li>\r
66<li>\r
67<p>\r
68Adam Chlipala has a\r
69<a href="http://adam.chlipala.net/mlcomp">point-by-point comparison</a> of OCaml\r
70and SML.\r
71</p>\r
72</li>\r
73</ul></div>\r
74</div>\r
75</div>\r
76<div class="sect1">\r
77<h2 id="_ocaml_and_mlton">OCaml and MLton</h2>\r
78<div class="sectionbody">\r
79<div class="paragraph"><p>Here&#8217;s a comparison of some aspects of OCaml and MLton.</p></div>\r
80<div class="ulist"><ul>\r
81<li>\r
82<p>\r
83Performance\r
84</p>\r
85<div class="ulist"><ul>\r
86<li>\r
87<p>\r
88Both OCaml and MLton have excellent performance.\r
89</p>\r
90</li>\r
91<li>\r
92<p>\r
93MLton performs extensive <a href="WholeProgramOptimization">WholeProgramOptimization</a>, which can\r
94provide substantial improvements in large, modular programs.\r
95</p>\r
96</li>\r
97<li>\r
98<p>\r
99MLton uses native types, like 32-bit integers, without any penalty\r
100due to tagging or boxing. OCaml uses 31-bit integers with a penalty\r
101due to tagging, and 32-bit integers with a penalty due to boxing.\r
102</p>\r
103</li>\r
104<li>\r
105<p>\r
106MLton uses native types, like 64-bit floats, without any penalty\r
107due to boxing. OCaml, in some situations, boxes 64-bit floats.\r
108</p>\r
109</li>\r
110<li>\r
111<p>\r
112MLton represents arrays of all types unboxed. In OCaml, only\r
113arrays of 64-bit floats are unboxed, and then only when it is\r
114syntactically apparent.\r
115</p>\r
116</li>\r
117<li>\r
118<p>\r
119MLton represents records compactly by reordering and packing the\r
120fields.\r
121</p>\r
122</li>\r
123<li>\r
124<p>\r
125In MLton, polymorphic and monomorphic code have the same\r
126performance. In OCaml, polymorphism can introduce a performance\r
127penalty.\r
128</p>\r
129</li>\r
130<li>\r
131<p>\r
132In MLton, module boundaries have no impact on performance. In\r
133OCaml, moving code between modules can cause a performance penalty.\r
134</p>\r
135</li>\r
136<li>\r
137<p>\r
138MLton&#8217;s <a href="ForeignFunctionInterface">ForeignFunctionInterface</a> is simpler than OCaml&#8217;s.\r
139</p>\r
140</li>\r
141</ul></div>\r
142</li>\r
143<li>\r
144<p>\r
145Tools\r
146</p>\r
147<div class="ulist"><ul>\r
148<li>\r
149<p>\r
150OCaml has a debugger, while MLton does not.\r
151</p>\r
152</li>\r
153<li>\r
154<p>\r
155OCaml supports separate compilation, while MLton does not.\r
156</p>\r
157</li>\r
158<li>\r
159<p>\r
160OCaml compiles faster than MLton.\r
161</p>\r
162</li>\r
163<li>\r
164<p>\r
165MLton supports profiling of both time and allocation.\r
166</p>\r
167</li>\r
168</ul></div>\r
169</li>\r
170<li>\r
171<p>\r
172Libraries\r
173</p>\r
174<div class="ulist"><ul>\r
175<li>\r
176<p>\r
177OCaml has more available libraries.\r
178</p>\r
179</li>\r
180</ul></div>\r
181</li>\r
182<li>\r
183<p>\r
184Community\r
185</p>\r
186<div class="ulist"><ul>\r
187<li>\r
188<p>\r
189OCaml has a larger community than MLton.\r
190</p>\r
191</li>\r
192<li>\r
193<p>\r
194MLton has a very responsive\r
195 <a href="http://www.mlton.org/mailman/listinfo/mlton">developer list</a>.\r
196</p>\r
197</li>\r
198</ul></div>\r
199</li>\r
200</ul></div>\r
201</div>\r
202</div>\r
203</div>\r
204<div id="footnotes"><hr></div>\r
205<div id="footer">\r
206<div id="footer-text">\r
207</div>\r
208<div id="footer-badges">\r
209</div>\r
210</div>\r
211</body>\r
212</html>\r
mlton packaging