Note that we already use functional boxes (eg. hvbox : int -> t -> t) and the compose function can be easily implemented on t -> t.

Only the code formatting modules uses imperative open/close functions and this is not making it safe (a little safer but not safe) and requires extra Box.unsafe_ functions.

I think that the main two benefits to this approach are:

• Box.t is a smaller type than t -> t, so we can introspect these more easily
• the unsafe API is explicit. it's easier to determine where the weird parts are compared to the existing API.

(this is not for immediate merge and won't solve all our issues but it's a good starting point to discuss some improvements - the API can be made lighter as well)

* the unsafe API is explicit. it's easier to determine where the weird parts are compared to the existing API.

I don't agree. The unsafe part of Box is used the way as the existing API. If it's about the name, we can more rename change open_*box into unsafe_open_*box, same for close_box.

I don't think we have an abstraction problem. The unsafe open/close functions are only used marginally and will be removed in the future.

Marking Format.open_*box would be useful, but there are cases that are more subtle. For example consider this piece of code:

It does not contain a call to Format.open_*box, however it breaks the balance between opn and cls. Box is made for these cases: you can't make open/closed unbalanced with just the safe API.

Does this make sense?

That makes sense. But I suggest to change this code to not use these functions instead. We tried before and did not succeed, though.

We'll find something better, closing.