<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hello,</div><div><br class="webkit-block-placeholder"></div><div>Here is the latest Caml Weekly News, for the week of December 11 to December 18, 2007.</div><div><br class="webkit-block-placeholder"></div><div>The Caml Weekly News will be taking a break next week. Happy holidays!</div><div><br class="webkit-block-placeholder"></div><div>1) CUFP Report Available</div><div>2) New contact address for the hump</div><div>3) First-class typed, direct-style sprintf</div><div>4) objsize-0.1</div><div>5) Jsure 1.0 Javascript checker</div><div>6) "Ref" and copy of functions</div><div>7) OCaml meeting in Paris</div><div>8) Camlp5 release 5.05</div><div><br class="webkit-block-placeholder"></div><div>========================================================================</div><div>1) CUFP Report Available</div><div>Archive: <<a href="http://groups.google.com/group/fa.caml/browse_frm/thread/58d732a29f4521ff#83bb57898b9c241c">http://groups.google.com/group/fa.caml/browse_frm/thread/58d732a29f4521ff#83bb57898b9c241c</a>></div><div>------------------------------------------------------------------------</div><div>** Kathleen Fisher announced:</div><div><br class="webkit-block-placeholder"></div><div>Jeremy Gibbons has written a very detailed report on the 2007 </div><div>Commercial Users of Functional Programming Workshop. His report is </div><div>available from the CUFP web page (<<a href="http://cufp.functionalprogramming.com">http://cufp.functionalprogramming.com</a>>) </div><div>as well as from the CUFP google group </div><div>page (<<a href="http://groups.google.com/group/cufp">http://groups.google.com/group/cufp</a>>). Thank you, Jeremy! </div><div><br class="webkit-block-placeholder"></div><div>Peter Thiemann and his students are just finishing up the post </div><div>processing of the recordings of the talks, and we are in the process </div><div>of getting those talks loaded onto the web. I'll send a further </div><div>announcement when the talks are available.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div>========================================================================</div><div>2) New contact address for the hump</div><div>Archive: <<a href="http://groups.google.com/group/fa.caml/browse_frm/thread/04a9ab9657fe8341#74a9140a02e15640">http://groups.google.com/group/fa.caml/browse_frm/thread/04a9ab9657fe8341#74a9140a02e15640</a>></div><div>------------------------------------------------------------------------</div><div>** Maxence Guesdon announced:</div><div><br class="webkit-block-placeholder"></div><div>The new (and working) e-mail address to contact the hump administrators is: </div><div> caml-hump "AT" inria.fr </div><div><br class="webkit-block-placeholder"></div><div>The Caml Hump: </div><div> <<a href="http://caml.inria.fr//cgi-bin/hump.en.cgi">http://caml.inria.fr//cgi-bin/hump.en.cgi</a>></div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div>========================================================================</div><div>3) First-class typed, direct-style sprintf</div><div>Archive: <<a href="http://groups.google.com/group/fa.caml/browse_frm/thread/5fd7b552a8e8b067#53c242b901f557db">http://groups.google.com/group/fa.caml/browse_frm/thread/5fd7b552a8e8b067#53c242b901f557db</a>></div><div>------------------------------------------------------------------------</div><div>** Oleg described:</div><div><br class="webkit-block-placeholder"></div><div>We demonstrate direct-style typed sprintf: sprintf format_spec arg1 arg2 .... </div><div>The type system ensures that the number and the types of format </div><div>specifiers in format_expression agree with the number and the types of </div><div>arg1, etc. Our sprintf and format specifiers are ordinary, </div><div>first-class functions, and so can be passed as arguments or returned </div><div>as results. The format specifiers can also be composed incrementally. </div><div>Unlike Danvy/Filinski's sprintf, the types seem to be simpler. </div><div><br class="webkit-block-placeholder"></div><div>Recently there has been discussion contrasting the OCaml Printf module </div><div>with Danvy/Filinski's functional unparsing. The latter can be </div><div>implemented as a pure library function, requiring no special support </div><div>from the compiler. It does require writing the format specifiers in </div><div>the continuation-passing style, which makes types huge and </div><div>errors very difficult to find. Perhaps less known that </div><div>Danvy/Filinski's functional unparsing has a direct-style </div><div>counter-part. It is particularly elegant and simple: the whole </div><div>implementation takes only four lines of code. The various </div><div>implementations of typed sprintf are lucidly and insightfully </div><div>described in </div><div> <<a href="http://pllab.is.ocha.ac.jp/~asai/papers/tr07-1.ps.gz">http://pllab.is.ocha.ac.jp/~asai/papers/tr07-1.ps.gz</a>> </div><div><br class="webkit-block-placeholder"></div><div>Alas, the elegant sprintf requires control operators supporting both </div><div>answer-type modification and polymorphism. The corresponding calculus </div><div>has been presented in the recent APLAS 2007 paper by Asai and </div><div>Kameyama. They have proven greatly desirable properties of their </div><div>calculus: strong type soundness, principal types, the existence of a </div><div>type inference algorithm, preservation of types and equality through </div><div>CPS translation, confluence, strong normalization for the subcalculus </div><div>without fix. </div><div> <<a href="http://logic.cs.tsukuba.ac.jp/~kam/paper/aplas07.pdf">http://logic.cs.tsukuba.ac.jp/~kam/paper/aplas07.pdf</a>> </div><div> <<a href="http://pllab.is.ocha.ac.jp/~asai/papers/aplas07slide.pdf">http://pllab.is.ocha.ac.jp/~asai/papers/aplas07slide.pdf</a>> </div><div><br class="webkit-block-placeholder"></div><div>At that time, only prototype implementation was available, in a </div><div>private version of mini-ML. Yesterday, a straightforward Haskell98 </div><div>implementation of the calculus emerged, based on parameterized monads: </div><div> <<a href="http://www.haskell.org/pipermail/haskell/2007-December/020034.html">http://www.haskell.org/pipermail/haskell/2007-December/020034.html</a>> </div><div>It includes sprintf. </div><div><br class="webkit-block-placeholder"></div><div>OCaml already has delimited control operators, in the delimcc </div><div>library. Those operators, too, support polymorphism. They are </div><div>different however, supporting multiple typed prompts, but the fixed </div><div>answer type (which is the type of the prompt). It has not been known </div><div>until today if the quantity of the prompts can make up for their </div><div>quality: can multi-prompt shift/reset (or, cupto) _emulate_ the </div><div>modification of the answer-type. We now know that the answer is yes. </div><div>Many elegant applications of shift/reset become possible; in </div><div>particular, `shift (fun k -> k)' becomes typeable. The latter has many </div><div>applications, e.g., in web form programming and linguistics. </div><div><br class="webkit-block-placeholder"></div><div>The full implementation and many tests (of sprintf) are available at </div><div> <<a href="http://okmij.org/ftp/ML/sprintf-cupto.ml">http://okmij.org/ftp/ML/sprintf-cupto.ml</a>> </div><div><br class="webkit-block-placeholder"></div><div>The following are a few notable excerpts. First are the definitions of </div><div>answer-type modifying, polymorphic shift/reset. Unlike the </div><div>fixed-answer-type shift/reset, which have one prompt, shift2/reset2 </div><div>have two prompts, for the two answer types (before and after the </div><div>modification). </div><div><br class="webkit-block-placeholder"></div><div>let reset2 f = </div><div> let p1 = new_prompt () in </div><div> let p2 = new_prompt () in </div><div> push_prompt p1 (fun () -> abort p2 (f (p1,p2)));; </div><div>val reset2 : ('a Delimcc.prompt * 'b Delimcc.prompt -> 'b) -> 'a = <fun> </div><div><br class="webkit-block-placeholder"></div><div>let shift2 (p1,p2) f = </div><div> shift p1 (fun k -> fun x -> </div><div> push_prompt p2 (fun () -> f k x; failwith "omega"));; </div><div>val shift2 : </div><div> ('a -> 'b) Delimcc.prompt * 'b Delimcc.prompt -> </div><div> (('c -> 'a -> 'b) -> 'a -> 'd) -> 'c = <fun> </div><div><br class="webkit-block-placeholder"></div><div>At first sight, these definitions seem trivial. At the second sight, </div><div>they seem outright wrong, as 'abort p2' seem to be executed before the </div><div>corresponding prompt p2 is pushed. Hopefully, the fifth sight will </div><div>show that the definitions are indeed simple and do what they are </div><div>supposed to. </div><div><br class="webkit-block-placeholder"></div><div>We can write the following append function (Sec 2.1 of Asai and </div><div>Kameyama's APLAS paper) </div><div><br class="webkit-block-placeholder"></div><div>let rec append lst prompts = </div><div> match lst with </div><div> | [] -> shift2 prompts (fun k l -> k l) </div><div> | a::rest -> a :: append rest prompts;; </div><div><br class="webkit-block-placeholder"></div><div>whose inferred type </div><div> 'a list -> ('a list -> 'b) Delimcc.prompt * 'b Delimcc.prompt -> 'a list </div><div>clearly shows both the polymorphism (in 'b) and the answer-type </div><div>modification from 'b to 'a list -> 'b. </div><div><br class="webkit-block-placeholder"></div><div>Here's the typed sprintf: </div><div><br class="webkit-block-placeholder"></div><div>let test3 = sprintf (lit "The value of " ^^ fmt str ^^ lit " is " ^^ fmt int);; </div><div> val test3 : string -> int -> string = <fun> </div><div>let test3r = test3 "x" 1;; </div><div> val test3r : string = "The value of x is 1" </div><div><br class="webkit-block-placeholder"></div><div>We can write this test in the following way, to demonstrate that </div><div>sprint and format specifiers are first-class and that the format </div><div>specification can be composed incrementally. </div><div><br class="webkit-block-placeholder"></div><div>let test3' = </div><div> let format_spec1 = lit "The value of " ^^ fmt str ^^ lit " is " in </div><div> let format_spec = format_spec1 ^^ fmt int in </div><div> let applyit f x = f x in </div><div> let formatter = applyit sprintf format_spec in </div><div> formatter "x" 1;; </div><div><br class="webkit-block-placeholder"></div><div>Here are the (inferred) types of format specifiers and of their compositions: </div><div><br class="webkit-block-placeholder"></div><div> # lit "xx";; </div><div> - : '_a Delimcc.prompt * '_a Delimcc.prompt -> string = <fun> </div><div><br class="webkit-block-placeholder"></div><div> # fmt int;; </div><div> - : (int -> '_a) Delimcc.prompt * '_a Delimcc.prompt -> string = <fun> </div><div> # fmt str;; </div><div> - : (string -> '_a) Delimcc.prompt * '_a Delimcc.prompt -> string = <fun> </div><div><br class="webkit-block-placeholder"></div><div> # fmt int ^^ lit "xx";; </div><div> - : (int -> '_a) Delimcc.prompt * '_a Delimcc.prompt -> string = <fun> </div><div><br class="webkit-block-placeholder"></div><div> # fmt int ^^ fmt str;; </div><div> - : (int -> string -> '_a) Delimcc.prompt * '_a Delimcc.prompt -> string =<fun> </div><div><br class="webkit-block-placeholder"></div><div>The type of (fmt int ^^ fmt str) clearly shows the answer-type </div><div>modification. One can read this as follows: given prompts, the </div><div>expression computes a string upon the hypotheses 'int' and 'string' in </div><div>that order.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div>========================================================================</div><div>4) objsize-0.1</div><div>Archive: <<a href="http://groups.google.com/group/fa.caml/browse_frm/thread/069b8cee302e699e#5c699ef3f5c71389">http://groups.google.com/group/fa.caml/browse_frm/thread/069b8cee302e699e#5c699ef3f5c71389</a>></div><div>------------------------------------------------------------------------</div><div>** Dmitry Grebeniuk announced:</div><div><br class="webkit-block-placeholder"></div><div> Some time ago there was a discussion about measuring </div><div>sizes of ocaml values. I've got some "round tuits" and </div><div>released a library that I use in my programs for some </div><div>years. Maybe it will be useful for other people too. </div><div> It is better than pure ocaml solutions because it </div><div>doesn't build hash table of visited values, and it uses </div><div>two bits for each visited value in worst case (but in my </div><div>practice it used no more than 120kb of additional memory </div><div>when I measured sizes of 300Mb-values). </div><div><br class="webkit-block-placeholder"></div><div>Readme: <<a href="http://89.187.37.10/gds/objsize/README">http://89.187.37.10/gds/objsize/README</a>> </div><div>Tarball: <<a href="http://89.187.37.10/gds/objsize/objsize-0.1.tar.gz">http://89.187.37.10/gds/objsize/objsize-0.1.tar.gz</a>></div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div>** Jon Harrop said and Dmitry Grebeniuk replied:</div><div><br class="webkit-block-placeholder"></div><div>> This doesn't seem to work on 64-bit. First I get: </div><div><br class="webkit-block-placeholder"></div><div> Thanks for testing, now it works on your platform too. </div><div><br class="webkit-block-placeholder"></div><div>Readme: <<a href="http://89.187.37.10/gds/objsize/README">http://89.187.37.10/gds/objsize/README</a>> </div><div>Tarball: <<a href="http://89.187.37.10/gds/objsize/objsize-0.11.tar.gz">http://89.187.37.10/gds/objsize/objsize-0.11.tar.gz</a>></div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div>========================================================================</div><div>5) Jsure 1.0 Javascript checker</div><div>Archive: <<a href="http://groups.google.com/group/fa.caml/browse_frm/thread/b4a7613afd790c6f#5f66bbade9416f59">http://groups.google.com/group/fa.caml/browse_frm/thread/b4a7613afd790c6f#5f66bbade9416f59</a>></div><div>------------------------------------------------------------------------</div><div>** Berke Durak announced:</div><div><br class="webkit-block-placeholder"></div><div>Jsure is a "lint" for Javascript, which is also known as Ecmascript. </div><div><br class="webkit-block-placeholder"></div><div>It checks syntax and a little bit of semantics (it's difficult to do </div><div>anything more sophisticated with real-world Javascript short of </div><div>interpreting it). </div><div><br class="webkit-block-placeholder"></div><div>We have been quite happy with it at Exalead for a few months now and so </div><div>we decided to release it under the LGPL. </div><div><br class="webkit-block-placeholder"></div><div>It is used daily to check the code in the Baagz <<a href="http://baagz.com/">http://baagz.com/</a>> project. </div><div><br class="webkit-block-placeholder"></div><div>It uses Aurochs as its parser (<<a href="http://aurochs.fr/">http://aurochs.fr/</a>>). </div><div><br class="webkit-block-placeholder"></div><div>You can get it at: </div><div><br class="webkit-block-placeholder"></div><div> <<a href="http://aurochs.fr/jsure.html">http://aurochs.fr/jsure.html</a>></div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div>========================================================================</div><div>6) "Ref" and copy of functions</div><div>Archive: <<a href="http://groups.google.com/group/fa.caml/browse_frm/thread/fbf1535f57fd5115#df8d80d702b7f1a5">http://groups.google.com/group/fa.caml/browse_frm/thread/fbf1535f57fd5115#df8d80d702b7f1a5</a>></div><div>------------------------------------------------------------------------</div><div>** Pierre-Evariste Dagand asked:</div><div><br class="webkit-block-placeholder"></div><div>I'm looking for advices about a "clean way" of doing something which, </div><div>by design, isn't. So, let states the problem. </div><div><br class="webkit-block-placeholder"></div><div>I'm doing a combinator library based on Arrows for a Yampa-like system : </div><div><br class="webkit-block-placeholder"></div><div>type ('a,'b) arrow = Arrow of ( 'a -> 'b ) </div><div><br class="webkit-block-placeholder"></div><div>Thus, I can instantiate an arrow with : </div><div><br class="webkit-block-placeholder"></div><div>let arr f = Arrow ( f ) </div><div>val arr : ('a -> 'b) -> ('a, 'b) arrow </div><div><br class="webkit-block-placeholder"></div><div>Then, I have, for example, the composition of arrows : </div><div><br class="webkit-block-placeholder"></div><div>let (>>>) (Arrow f) (Arrow g) =Arrow ( fun c -> g ( f c ) ) </div><div>val ( >>> ) : ('a, 'b) arrow -> ('b, 'c) arrow -> ('a, 'c) arrow </div><div><br class="webkit-block-placeholder"></div><div>Right here, everything plays well (excepted some weak type variables </div><div>issues but that's not a big deal). </div><div><br class="webkit-block-placeholder"></div><div>But (and that's here that the trouble is) I need a "loop" combinator, </div><div>that I wrote this way : </div><div><br class="webkit-block-placeholder"></div><div>let loop init (Arrow f) = </div><div> let state = ref init in </div><div> Arrow ( </div><div> fun c -> </div><div> let new_state , output = f ( !state , c ) in </div><div> state := new_state; </div><div> output </div><div> ) </div><div>val loop : 'a -> ('a * 'b, 'a * 'c) arrow -> ('b, 'c) arrow </div><div><br class="webkit-block-placeholder"></div><div>Finally, I can write a small arrow : </div><div><br class="webkit-block-placeholder"></div><div>let arr_counter = loop 0 ( arr ( fun ( counter , x ) -> counter+1 , </div><div>counter+x ) ) </div><div>let arr_double = arr ( fun x -> 2*x ) </div><div>let arr_my_small_arrow = arr_counter >>> arr_double </div><div><br class="webkit-block-placeholder"></div><div>And I execute it with : </div><div><br class="webkit-block-placeholder"></div><div>let run (Arrow f) input = </div><div> f input </div><div>val run : ('a, 'b) arrow -> 'a -> 'b </div><div><br class="webkit-block-placeholder"></div><div>And it works. Right. </div><div><br class="webkit-block-placeholder"></div><div>But now, I would like to be able to "copy" a built arrow and to be </div><div>able to execute the copy without side-effecting on the first one. </div><div>Obviously, I cannot do that in this implementation. </div><div><br class="webkit-block-placeholder"></div><div>My current solution is really *ugly* : </div><div><br class="webkit-block-placeholder"></div><div>let arrow_string = Marshal.to_string arrow [ Marshal.No_sharing ; </div><div>Marshal.Closures ] </div><div><br class="webkit-block-placeholder"></div><div>Then I "Marshal.from_string arrow_string". I'm not even sure if it </div><div>will not blow out of my hands with "strange" things in the Ref cell. </div><div><br class="webkit-block-placeholder"></div><div>I'm aware of implementations in CPS but I use to think that it has a </div><div>performance cost that I'm not ready to pay (I'm fighting against a C++ </div><div>code so...). </div><div><br class="webkit-block-placeholder"></div><div>So if someone knows an elegant solution to my problem (if someone has </div><div>read this mail until here), please let me know :-) </div><div><br class="webkit-block-placeholder"></div><div>Best regards, </div><div><br class="webkit-block-placeholder"></div><div>P.S.: For those who are just curious, these combinators are used in a </div><div>functional-reactive library for Peer-to-Peer overlays programming.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div>** Oleg suggested:</div><div><br class="webkit-block-placeholder"></div><div>If you like using the mutable state, perhaps you might find the </div><div>following code helpful. The key idea is packaging the clone function </div><div>along with the arrow. There is no longer any need in any unsafe </div><div>features. The lesson from our tagless final APLAS paper is that many </div><div>things are significantly easier if we do the work at the production </div><div>site rather than at the consumption site. </div><div><br class="webkit-block-placeholder"></div><div>(* The first component is the arrow itself, the second one is the clone </div><div> function*) </div><div>type ('a,'b) arrow = {arrow: 'a -> 'b; clone: unit -> ('a,'b) arrow};; </div><div><br class="webkit-block-placeholder"></div><div>let rec arr f = {arrow = f; clone = fun () -> arr f};; </div><div><br class="webkit-block-placeholder"></div><div>let rec (>>>) f g = {arrow = (fun c -> g.arrow (f.arrow c)); </div><div> clone = (fun () -> f.clone () >>> g.clone ())};; </div><div><br class="webkit-block-placeholder"></div><div>(* Here, our clone function uses the initial state rather than the </div><div>current state. It is trivial to clone from the current state, if </div><div>desired.*) </div><div><br class="webkit-block-placeholder"></div><div>let rec loop init f = </div><div> let state = ref init in </div><div> {arrow = </div><div> (fun c -> </div><div> let new_state , output = f.arrow ( !state , c ) in </div><div> state := new_state; </div><div> output); </div><div> clone = (fun () -> loop init (f.clone ()))};; </div><div><br class="webkit-block-placeholder"></div><div>let arr_counter = loop 0 (arr (fun (counter, x) -> counter+1 ,counter+x));; </div><div>let arr_double = arr (fun x -> 2*x);; </div><div>let arr_my_small_arrow = arr_counter >>> arr_double;; </div><div><br class="webkit-block-placeholder"></div><div>let run f input = let v1 = f.arrow input in </div><div> let v2 = f.arrow input in </div><div> (v1,v2);; </div><div><br class="webkit-block-placeholder"></div><div>let test1 = run arr_my_small_arrow 10;; </div><div> val test1 : int * int = (20, 22) </div><div><br class="webkit-block-placeholder"></div><div>let test2 = run arr_my_small_arrow 10;; </div><div> val test2 : int * int = (24, 26) (*obviously, counter keeps </div><div> counting *) </div><div><br class="webkit-block-placeholder"></div><div>let test3 = run (arr_my_small_arrow.clone ()) 10;; </div><div>val test3 : int * int = (20, 22) (* cloning `resets' the counter *)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div>** Jacques Garrigue also suggested:</div><div><br class="webkit-block-placeholder"></div><div>Here is yet another solution, using objects, which actually combines </div><div>Zheng's and Oleg's ideas. That is, it separates state and function, </div><div>but provides only access to state through a cloning method, so that it </div><div>is completely type safe. This is just what objects are good at! </div><div><br class="webkit-block-placeholder"></div><div>class ['a,'b] arrow (f : 'a -> 'b) = </div><div> object (self) method call = f method copy = self end </div><div><br class="webkit-block-placeholder"></div><div>let (>>>) rf rg : ('a,'b) arrow = </div><div> object </div><div> val rf : ('a,'c) arrow = rf </div><div> val rg : ('c,'b) arrow = rg </div><div> method call x = rg#call (rf#call x) </div><div> method copy = {< rf = rf#copy; rg = rg#copy >} </div><div> end </div><div><br class="webkit-block-placeholder"></div><div>let loop init rf : ('b,'c) arrow = </div><div> object </div><div> val mutable state = init </div><div> val rf : ('a*'b,'a*'c) arrow = rf </div><div> method call x = </div><div> let state', y = rf#call (state, x) in </div><div> state <- state'; y </div><div> method copy = {< rf = rf#copy >} </div><div> end </div><div><br class="webkit-block-placeholder"></div><div>let arr = new arrow </div><div>let arr_counter = loop 0 (arr (fun (counter,x) -> counter+1, counter+x)) </div><div>let arr_double = arr (fun x -> 2*x) </div><div>let arr_my_small_arrow = arr_counter >>> arr_double </div><div><br class="webkit-block-placeholder"></div><div>The key here is the {< ... >} construct, which creates a shallow copy </div><div>of an object, eventually with some fields changed. As a result, in </div><div>loop there is no need to handle the state explicitly: the state field </div><div>in the copied object will be distinct from the state field in the </div><div>original object. On the other hand, you must explicitly update fields </div><div>holding arrows, since the copy is shallow. Note that the explicit </div><div>"val" fields are needed to allow updating their contents when copying. </div><div><br class="webkit-block-placeholder"></div><div>One difference with Oleg's approach is that we take a copy of the </div><div>original object, rather than creating a completely new record. In this </div><div>case, this doesn't mean much, since there is no extra computation </div><div>involved. Still, the state after copying is not the original but the </div><div>current one. And this may matter more if the construction is more </div><div>complicated.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div>** Pierre-Evariste Dagand replied:</div><div><br class="webkit-block-placeholder"></div><div>Yet another nice solution I would never have imagined :-) </div><div><br class="webkit-block-placeholder"></div><div>And the performance is quite good : </div><div><br class="webkit-block-placeholder"></div><div>1.428032 microseconds on my small benchmark </div><div><br class="webkit-block-placeholder"></div><div>(the unsafe Ref implantation takes 0.75 microseconds while the CPS </div><div>implantation takes 2.7 microseconds). </div><div><br class="webkit-block-placeholder"></div><div>Nevertheless, I have carried out my benchmark on Oleg's implementation </div><div>and find an impressive performance : </div><div><br class="webkit-block-placeholder"></div><div>0.74 microseconds ! </div><div><br class="webkit-block-placeholder"></div><div>Now, I will re-write my combinators and see which style better suits my needs.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div>** Pierre-Evariste Dagand finally added:</div><div><br class="webkit-block-placeholder"></div><div>Finally, impressed by the speed of the record solution, I have </div><div>re-written the whole library with records. </div><div><br class="webkit-block-placeholder"></div><div>I have measured the performance of this implementation against the </div><div>Ref-based one on "real" code. Thus, I have simulated my Chord [1] </div><div>implementation with a simulator instrumented such that it drops the </div><div>processing time for each arrow processing. </div><div><br class="webkit-block-placeholder"></div><div>The results can be found at [2]. </div><div><br class="webkit-block-placeholder"></div><div>In a nutshell : the record solution has a negligible overhead compared </div><div>to the Ref solution. </div><div><br class="webkit-block-placeholder"></div><div>Thanks all, </div><div><br class="webkit-block-placeholder"></div><div>[1]: <<a href="http://pdos.csail.mit.edu/chord/">http://pdos.csail.mit.edu/chord/</a>> </div><div>[2]: <<a href="http://perso.eleves.bretagne.ens-cachan.fr/~dagand/projets/opis/processing_speed_records.pdf">http://perso.eleves.bretagne.ens-cachan.fr/~dagand/projets/opis/processing_speed_records.pdf</a>></div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div>========================================================================</div><div>7) OCaml meeting in Paris</div><div>Archive: <<a href="http://groups.google.com/group/fa.caml/browse_frm/thread/844f6a6880371cbd#8f748cc03a025c4f">http://groups.google.com/group/fa.caml/browse_frm/thread/844f6a6880371cbd#8f748cc03a025c4f</a>></div><div>------------------------------------------------------------------------</div><div>** It the middle of a thread, Berke Durak said:</div><div><br class="webkit-block-placeholder"></div><div>I agree. I think Ocamlfind and Godi are nice pieces of work, and it </div><div>certainly would be better if we could integrate existing systems. </div><div><br class="webkit-block-placeholder"></div><div>We all love Ocaml, but there seems to be an important problem with it. </div><div><br class="webkit-block-placeholder"></div><div>Unlike most programming languages of similar magnitude, Ocaml doesn't </div><div>have a developer conference where its users could meet face-to-face and </div><div>discuss these kind of things... (or did I miss something?) If not, we </div><div>should organize one. </div><div><br class="webkit-block-placeholder"></div><div>Ocaml users span half a dozen continents but we could start with a small </div><div>gathering in Paris. I'd suggest late January. </div><div><br class="webkit-block-placeholder"></div><div>We could then discuss distribution, building, packaging and other </div><div>issues; and publish guidelines for a "request for implementation" -- </div><div>things we would like to see in an integrated compilation and package </div><div>manager. </div><div><br class="webkit-block-placeholder"></div><div>People would then implement different solutions and we could gather two </div><div>months later to evaluate the proposals. </div><div><br class="webkit-block-placeholder"></div><div>Does anyone have a proposal for a gathering place?</div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div>** The editor said:</div><div><br class="webkit-block-placeholder"></div><div>There have been many replied, suggesting dates and places. Please follow </div><div>the archive link above if you are interested.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div><div>========================================================================</div><div>8) Camlp5 release 5.05</div><div>Archive: <<a href="http://groups.google.com/group/fa.caml/browse_frm/thread/bde6e55ecd4ba192#7c2ef011bd661100">http://groups.google.com/group/fa.caml/browse_frm/thread/bde6e55ecd4ba192#7c2ef011bd661100</a>></div><div>------------------------------------------------------------------------</div><div>** Daniel de Rauglaudre announced:</div><div><br class="webkit-block-placeholder"></div><div>New release of Camlp5: 5.05 </div><div><br class="webkit-block-placeholder"></div><div>Changes: </div><div> - added function Pcaml.quotation_location returning, in quotation </div><div> expanders, the location of the quotation in the source file. </div><div> - added generation of the file META for ocamlfind (built in </div><div> directory "etc"). </div><div> - some bug fixes and improvements. </div><div><br class="webkit-block-placeholder"></div><div>See the Camlp5 documentation and the file CHANGES. </div><div><br class="webkit-block-placeholder"></div><div>Download the sources and the documentation at: </div><div> <<a href="http://pauillac.inria.fr/~ddr/camlp5/">http://pauillac.inria.fr/~ddr/camlp5/</a>></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 class="webkit-block-placeholder"></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 class="webkit-block-placeholder"></div><div>========================================================================</div><div>Old cwn</div><div>------------------------------------------------------------------------</div><div><br class="webkit-block-placeholder"></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 class="webkit-block-placeholder"></div><div>========================================================================</div><div><br class="webkit-block-placeholder"></div><div><br></div><div class="AppleMailSignature" id="E12A09DE-ADCF-40D6-B7D4-306ED5CADD30"><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>