<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hello,</div><div><br></div><div>Here is the latest Caml Weekly News, for the week of March 17 to 24, 2009.</div><div><br></div><div>1) XML output</div><div>2) ocaml-http is looking for a new maintainer</div><div>3) Google summer of Code proposal</div><div><br></div><div>========================================================================</div><div>1) XML output</div><div>Archive: <<a href="http://groups.google.com/group/fa.caml/browse_thread/thread/165323537f036e34#">http://groups.google.com/group/fa.caml/browse_thread/thread/165323537f036e34#</a>></div><div>------------------------------------------------------------------------</div><div>** Rémi Dewitte asked and Gerd Stolpmann answered:</div><div><br></div><div>> I have used pxp to parse xml and I am happy with it. I'd like now to</div><div>> produce xml and wonder what are the options to do so (possibly the</div><div>> simpliest).</div><div><br></div><div>Maybe not the simplest: Use the PXP preprocessor to create the output</div><div>tree, and print the tree:</div><div><br></div><div><<a href="http://projects.camlcity.org/projects/dl/pxp-1.2.1/doc/manual/html/ref/Intro_preprocessor.html">http://projects.camlcity.org/projects/dl/pxp-1.2.1/doc/manual/html/ref/Intro_preprocessor.html</a>></div><div><<a href="http://projects.camlcity.org/projects/dl/pxp-1.2.1/doc/manual/html/ref/Pxp_document.document.html#2_WritingdocumentsasXMLtext">http://projects.camlcity.org/projects/dl/pxp-1.2.1/doc/manual/html/ref/Pxp_document.document.html#2_WritingdocumentsasXMLtext</a>></div><div><br></div><div><br></div><div>> </div><div>> I think I am going to start with the Printf module. I wonder how well</div><div>> it handles utf8 for example. </div><div><br></div><div>UTF-8 are just bytes for printf.</div><div><br></div><div>> And I'll have to write a kind of xml_encode function. I am pretty sure</div><div>> it has already be done somewhere !</div><div><br></div><div>let xml_encode =</div><div> Netencoding.Html.encode </div><div> ~in_enc:`Enc_utf8</div><div> ~out_enc:`Enc_usascii</div><div> ~prefer_names:false</div><div> ()</div><div><br></div><div>That would assume the input is UTF-8 encoded, and the output is</div><div>ASCII-encoded. You can control which ASCII characters get the special</div><div>XML representation &...; with the unsafe_chars optional argument.</div><div>Docs are at</div><div><<a href="http://projects.camlcity.org/projects/dl/ocamlnet-2.2.9/doc/html-main/Netencoding.Html.html">http://projects.camlcity.org/projects/dl/ocamlnet-2.2.9/doc/html-main/Netencoding.Html.html</a>></div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div>** Sylvain Le Gall also replied:</div><div><br></div><div>Maybe it is a bit overkilling, but there is also ocamlduce.</div><div><br></div><div>See there:</div><div><<a href="http://www.cduce.org/ocaml">http://www.cduce.org/ocaml</a>></div><div>(dev for ocaml 3.11:)</div><div><<a href="http://ocamlduce.forge.ocamlcore.org/">http://ocamlduce.forge.ocamlcore.org/</a>></div><div><<a href="http://git.ocamlcore.org/cgi-bin/gitweb.cgi?p=ocamlduce/ocamlduce.git;a=summary">http://git.ocamlcore.org/cgi-bin/gitweb.cgi?p=ocamlduce/ocamlduce.git;a=summary</a>></div><div><br></div><div>OCamlduce can also be used with Eliom/OCsigen.</div><div><br></div><div>AFAIK, using ocamlduce can help you to type check your output tree</div><div>directly within OCaml compiler...</div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div>** Matthieu Wipliez also replied:</div><div><br></div><div>Yet another solution is Xmlm by Daniel Bünzli.</div><div><br></div><div><<a href="http://erratique.ch/software/xmlm">http://erratique.ch/software/xmlm</a>></div><div><br></div><div>This is probably the easiest and lightweight solution: Xmlm comes as a single</div><div>module and its interface, and it's BSD so you can just copy/paste it into your</div><div>project.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div>** Michael Ekstrand then added:</div><div><br></div><div>I second the xmlm suggestion. Polling event-based parsing is very slick </div><div>and maps well into the functional paradigm, and its XML writing support </div><div>(generating a stream of events identical to those you read) makes </div><div>generation quite intuitive and reliable.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div>========================================================================</div><div>2) ocaml-http is looking for a new maintainer</div><div>Archive: <<a href="http://groups.google.com/group/fa.caml/browse_thread/thread/3e99820fd9b65b57#">http://groups.google.com/group/fa.caml/browse_thread/thread/3e99820fd9b65b57#</a>></div><div>------------------------------------------------------------------------</div><div>** Stefano Zacchiroli announced:</div><div><br></div><div>Hi all, ocaml-http [1] is looking for a new maintainer.</div><div>More details have been written on my blog [2].</div><div><br></div><div>If you are interested in taking over the maintenance, please mail me</div><div>in private.</div><div><br></div><div>Cheers.</div><div><br></div><div>[1] <<a href="http://upsilon.cc/~zack/hacking/software/ocaml-http/">http://upsilon.cc/~zack/hacking/software/ocaml-http/</a>></div><div>[2] <<a href="http://upsilon.cc/~zack/blog/posts/2009/03/ocaml-http_is_looking_for_a_new_maintainer/">http://upsilon.cc/~zack/blog/posts/2009/03/ocaml-http_is_looking_for_a_new_maintainer/</a>></div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div>========================================================================</div><div>3) Google summer of Code proposal</div><div>Archive: <<a href="http://groups.google.com/group/fa.caml/browse_thread/thread/3249f410fe061579#">http://groups.google.com/group/fa.caml/browse_thread/thread/3249f410fe061579#</a>></div><div>------------------------------------------------------------------------</div><div>** In this long thread full of technical posts, Andrey Riabushenko said and Xavier Leroy replied:</div><div><br></div><div>> I would like to develop LLVM frontend to Ocaml language. LLVM does participate</div><div>> in GSoC. LLVM do not mind to developed a ocaml frontend as LLVM GSoC project.</div><div>> I want to discuss details with you before I will make an official proposal to</div><div>> LLVM. [...]</div><div><br></div><div>Do authors of ocaml has something to say about the idea?</div><div><br></div><div>Da. A number of things, actually.</div><div><br></div><div>1- I know of at least 3, maybe 4 other projects that want to do</div><div>something with OCaml and LLVM. Clearly, some coordination between</div><div>these efforts is needed.</div><div><br></div><div>2- If you're applying for funding through a summer of code project,</div><div>you need to articulate good reasons why you want to combine OCaml and</div><div>LLVM. "Ocaml is cool, LLVM is cool, so OCaml+LLVM would be extra</div><div>cool" is not enough. "It will generate PIC-16 code" isn't either.</div><div>Run-time code generation could be a good enough reason, but you still</div><div>need to weigh the development cost of the LLVM approach against, for</div><div>example, hacking the current OCaml code generator so that it emits</div><div>machine code in memory instead of assembly code.</div><div><br></div><div>3- A language implementation like OCaml breaks down in four big parts:</div><div> 1- Front-end compiler</div><div> 2- Back-end compiler and code emitter</div><div> 3- Run-time system</div><div> 4- OS interface</div><div>Of these four, the back-end is not the biggest part nor the most</div><div>complicated part. LLVM gives you part 2, but you still need to</div><div>consider the other 3 parts. Saying "I'll do 1, 3 and 4 from scratch",</div><div>Harrop-style, means a 5-year project. To get somewhere within a</div><div>reasonable amount of time, you really need to reuse large parts of the</div><div>existing OCaml code base.</div><div><br></div><div>4- From a quick look at LLVM specs, the two aspects that appear most</div><div>problematic w.r.t. Caml are exception handling and GC interface.</div><div>LLVM seems to implement C++/Java "zero-cost" exceptions, which are</div><div>known to be quite costly for Caml. (Been there, done that, in the</div><div>early 1990s.) I regret that LLVM does not provide support for</div><div>alternate implementations of exceptions, like the C-- intermediate</div><div>language of Ramsey et al does:</div><div> <<a href="http://portal.acm.org/citation.cfm?id=349337">http://portal.acm.org/citation.cfm?id=349337</a>></div><div><br></div><div>The big issue, however, is GC interface. There are GC techniques that</div><div>need no support from the back-end: stack maps and conservative</div><div>collection. Stack maps are very costly in execution time.</div><div>Conservative GC like the Boehm-Weiser GC is already much better. But</div><div>for full efficiency, back-end support is required. LLVM documents a</div><div>minimal interface to produce stack maps and make them available to the</div><div>GC at run-time:</div><div> <<a href="http://llvm.org/docs/GarbageCollection.html">http://llvm.org/docs/GarbageCollection.html</a>></div><div><br></div><div>The first thing you want to investigate is whether this interface is</div><div>enough to support an exact, relocating collector such as</div><div>OCaml's. According to</div><div> <<a href="http://www.nabble.com/Garbage-collection-td22219430.html">http://www.nabble.com/Garbage-collection-td22219430.html</a>></div><div>Gordon Henriksen did succeed in interfacing OCaml's GC with LLVM.</div><div>Maybe there is still some more work to do here, in which case I</div><div>recommend you look into this first.</div><div><br></div><div>6- Here is a schematic of the Caml compiler. (Use a fixed-width font.)</div><div><br></div><div> |</div><div> | parsing and preprocessing</div><div> v</div><div> Parsetree (untyped AST)</div><div> |</div><div> | type inference and checking</div><div> v</div><div> Typedtree (type-annotated AST)</div><div> |</div><div> | pattern-matching compilation, elimination of modules, classes</div><div> v</div><div> Lambda</div><div> / \</div><div> / \ closure conversion, inlining, uncurrying,</div><div> v \ data representation strategy</div><div> Bytecode \</div><div> \</div><div> Cmm</div><div> |</div><div> | code generation</div><div> v</div><div> Assembly code</div><div><br></div><div>In my opinion, the simplest approach is to start at Cmm and generate</div><div>LLVM code from there. Starting at one of the higher-level</div><div>intermediate forms would entail reimplementing large chunks of the</div><div>OCaml compiler. Note that Cmm is quite close to the C-- intermediate</div><div>language mentioned earlier, so there is a lot to learn from Fermin</div><div>Reig's experience with an OCaml/C-- back-end.</div><div><br></div><div>7- To finish, I'll preventively deflect some likely reactions by Jon</div><div>Harrop:</div><div><br></div><div>"But you'll be tied to OCaml's data representation strategy!"</div><div> Right, but 1- implementing you own data representation strategy is</div><div> a lot of work, especially if it is type-based, and 2- OCaml's</div><div> strategy is close to optimal for symbolic computing.</div><div><br></div><div>"But LLVM assembly is typed, so you must have types!"</div><div> Just use int32 or int64 as your universal type and cast to</div><div> appropriate pointer types in loads or stores.</div><div><br></div><div>"But your code will be tainted by OCaml's evil license!"</div><div> It is trivial to make ocamlopt dump Cmm code in a file or pipe.</div><div> (The -dcmm debug option already does this.) Then, you can have a</div><div> separate, untainted program that reads the Cmm code and transforms it.</div><div><br></div><div>"But shadow stacks are the only way to go for GC interface!"</div><div> No, it's probably the worst approach performance-wise; even a</div><div> conservative GC should work better.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div>** Jon Harrop replied:</div><div><br></div><div>> 3- A language implementation like OCaml breaks down in four big parts:</div><div>> 1- Front-end compiler</div><div>> 2- Back-end compiler and code emitter</div><div>> 3- Run-time system</div><div>> 4- OS interface</div><div>> Of these four, the back-end is not the biggest part nor the most</div><div>> complicated part. LLVM gives you part 2, but you still need to</div><div>> consider the other 3 parts. Saying "I'll do 1, 3 and 4 from scratch",</div><div>> Harrop-style, means a 5-year project.</div><div><br></div><div>On the contrary, my "style" was to provide the features that I value </div><div>(multicore & FFI) in a usable form (stop-the-world) with the shortest </div><div>possible development time (i.e. <<6 months to create something useful). </div><div>Specifically:</div><div><br></div><div>1- Front-end compiler: use camlp4 to provide an embedded DSL for </div><div>high-performance parallel numerics and/or reuse front-ends from existing </div><div>compilers like OCaml, PolyML, MosML, NekoML to build completely new language </div><div>implementations.</div><div><br></div><div>2- Back-end compiler and code emitter: reuse LLVM.</div><div><br></div><div>3- Run-time system: write the simplest possible precise GC and use </div><div>stop-the-world to apply it to threads that may then run in parallel.</div><div><br></div><div>4- OS interface: make it as easy as possible to call C directly.</div><div><br></div><div>HLVM had solved (2), (3) and (4) after only 3 months of part-time work. I </div><div>vindicated my style!</div><div><br></div><div>> 7- To finish, I'll preventively deflect some likely reactions by Jon</div><div>> Harrop:</div><div>> </div><div>> "But you'll be tied to OCaml's data representation strategy!"</div><div>> Right, but 1- implementing you own data representation strategy is</div><div>> a lot of work, especially if it is type-based, and</div><div><br></div><div>Actually I found that easy, not least because I wanted a user-friendly FFI so </div><div>I just used C's data representation whenever possible.</div><div><br></div><div>> 2- OCaml's strategy is close to optimal for symbolic computing.</div><div><br></div><div>Is MLton not several times faster than OCaml for symbolic computing?</div><div><br></div><div>> "But LLVM assembly is typed, so you must have types!"</div><div>> Just use int32 or int64 as your universal type and cast to</div><div>> appropriate pointer types in loads or stores.</div><div><br></div><div>That is entirely possible and could be useful as an incremental improvement to </div><div>OCaml's existing bytecode interpreter but it is not a step toward my goals.</div><div><br></div><div>> "But your code will be tainted by OCaml's evil license!"</div><div>> It is trivial to make ocamlopt dump Cmm code in a file or pipe.</div><div>> (The -dcmm debug option already does this.) Then, you can have a</div><div>> separate, untainted program that reads the Cmm code and transforms it.</div><div><br></div><div>Again, that is another technically-feasible step away from my goals because </div><div>OCaml's CMM has already been mangled for its data representation (e.g. 31-bit </div><div>ints, boxed floats).</div><div><br></div><div>> "But shadow stacks are the only way to go for GC interface!"</div><div>> No, it's probably the worst approach performance-wise; even a</div><div>> conservative GC should work better.</div><div><br></div><div>Building a state-of-the-art optimized concurrent GC Leroy-style means an </div><div>infinity-year project. =:-p</div><div><br></div><div>Seriously though, I think it is essential to get a first working version of a </div><div>GC that permits parallel threads. HLVM will be useful to a lot of people long </div><div>before its GC gets optimized.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div>========================================================================</div><div>Using folding to read the cwn in vim 6+</div><div>------------------------------------------------------------------------</div><div>Here is a quick trick to help you read this CWN if you are viewing it using</div><div>vim (version 6 or greater).</div><div><br></div><div>:set foldmethod=expr</div><div>:set foldexpr=getline(v:lnum)=~'^=\\{78}$'?'<1':1</div><div>zM</div><div>If you know of a better way, please let me know.</div><div><br></div><div>========================================================================</div><div>Old cwn</div><div>------------------------------------------------------------------------</div><div><br></div><div>If you happen to miss a CWN, you can send me a message</div><div>(<a href="mailto:alan.schmitt@polytechnique.org">alan.schmitt@polytechnique.org</a>) and I'll mail it to you, or go take a look at</div><div>the archive (<<a href="http://alan.petitepomme.net/cwn/">http://alan.petitepomme.net/cwn/</a>>) or the RSS feed of the</div><div>archives (<<a href="http://alan.petitepomme.net/cwn/cwn.rss">http://alan.petitepomme.net/cwn/cwn.rss</a>>). If you also wish</div><div>to receive it every week by mail, you may subscribe online at</div><div><<a href="http://lists.idyll.org/listinfo/caml-news-weekly/">http://lists.idyll.org/listinfo/caml-news-weekly/</a>> .</div><div><br></div><div>========================================================================</div><div class="AppleMailSignature" id="E12A09DE-ADCF-40D6-B7D4-306ED5CADD30"> <div><br class="khtml-block-placeholder"></div><div>-- </div><div>Alan Schmitt <<a href="http://alan.petitepomme.net/">http://alan.petitepomme.net/</a>></div><div><br class="khtml-block-placeholder"></div><div>The hacker: someone who figured things out and made something cool happen.</div><div> .O.</div><div> ..O</div><div> OOO</div><br class="Apple-interchange-newline"> </div><br></body></html>