Gagallium

Sometimes using OCAMLRUNPARAM="b" returns a disappointingly unhelpful backtrace, because the program you're trying to debug has a non-trivial usage of exceptions that destroys the backtrace information you were expecting. Here is a new library that should solve this problem, by allowing you to reliably register backtraces. Read more for the source, and the juicy internal details: weak tables, semi-manual garbage collection logic, and an optional change to the OCaml runtime to improve the library performances.

Batteries contributors recently started a new discussion on the Enum module, whose purpose is to provide an good intermediate representation for conversion between data-structures, but whose implementation is perceived as too complicated and not well-understood enough. Going back to fundamentals (forgetting about half the features of Enum), what is the ultimate intermediate traversal interface?

There are two obvious choices in an effectful setting: a generator, that is a “next-element” function of type (unit -> 'a) that generates the next element each time it is called, or an exception to signal end of input; or an iterator, a fold-function of type ('a -> unit) -> unit, that iterates a consumer function through all elements of the list.

Both are suitable as an abstract representation of any sequence (the second is precisely the basis for Simon Cruanes’ Sequence library), and their are at opposite ends of the control spectrum: generators give control to the consumer of the sequence (she decides when to call the generator function), while iterators give control to the producer of the sequence (she decides when to call the iterated function). It’s easy to transform a structure into a iter (to_iter), or to build a structure from a next (of_next), because you have the control. But as a library writer, you should also write the without-control conversions (of_iter and to_next), despite them being slower and harder to implement, so that your users can live the easy in-control life!

Finally, continuation capture is a well-known technique to invert control, letting you write code in “direct style”, as if you were in control, when you’re not. In this post, I will demonstrate how you can start from a conversion function that has control and, by systematic source-to-source transformations of conversion to continuation-passing-style (CPS) and defunctionalization, obtain a conversion function that works without the control.