[MLton] Optional Arguments and FRU

[Stephen Weeks]

> I think that providing a FRU "set" (or "opt") function for each (or
> most) argument record in a library can be reasonable and even
> commendable.

Maybe.  I've lived without FRU for so long that I don't have a good
feel for what I'm missing.

> A user can build more convenient notations on top of that. OTOH,
> providing a separate function for each optional argument can easily
> be overkill.

I don't know.  It's almost certainly more lines of interface code, but
that doesn't necessarily equal complexity.  I think we should at least
look at complete example signatures of each case side by side to
compare.

> Also, if you provide a certain style of interface in one place, it
> is a good idea to use the same style in other places (withing a
> library) to ease the learning curve.

Agreed!  I use the substructure/type t style everywhere in my SML
code, so it is actually quite consistent with my style.  Those
familiar with the style find it automatic when they see FArg.t to know
that all of the relevant functions for constructing and manipulating
values of type FArg.t are in the FArg substructure.

> I'm just trying to elaborate on why I don't find it best to always
> minimize the client code. I've explored it in the past and I think
> that, like most things, it isn't always the optimal
> approach. (State-of-the-art C++ libraries often go through hoops
> just to make the notation bearable while maintaining maximal
> performance. As a consequence, the implementation becomes unreadable
> to just about anyone but the library author and a few experts.)

I don't disagree in general, although I don't think arguments based on
implementation difficulty are relevant in the situations we have been
talking about -- all the implementations we have been looking at are
trivial.  I also think that it is dangerous to conclude much by
analogy with C++ libraries, since the granularity of modules is so
different and the difficulty of implementing anything there is so much
higher.  In any case, for OA, I think the question comes down to other
issues: performance, documentation, consistency, and simplicity of
client.

> It seems, then, that composition + FRU is the preferred (simple & efficient)
> way to get a reasonable OA interface (whether or not you want to provide a
> function for each argument). CPS + FRU (likely to be most efficient) and
> list + FRU (appealing syntax, but possibly inefficient) are worth mentioning
> as alternatives.

I'm leaning toward CPS + FRU as the preferred way, especially because
of the observations about its generality in my last email.