[MLton] Optional Arguments and FRU

[Vesa Karvonen]

Quoting Stephen Weeks <sweeks@sweeks.com>:
> > >   val z = f' 10 (a 1.0 & c 2 & b 1.0)
> > 
> > Although it is notationally nice, I think that the extra code needed to
> > implement it may not always be worth it. 
> 
> I'm generally more concerned about concision of client code than
> concision of implementation.

As a library author you can not always easily predict which approach yields
the most appealing interface. Users' (style) preferences may differ.

Suppose you would provide a "convenient" optional arguments notation for a large
number of functions in a library. The library documentation/interface could
become quite bloated with the details, which could reduce the appeal or steepen
the learning curve of the interface. At the same time, the implementation could
also become quite bloated and the cost of maintaining it might not be worth the
relatively small convenience to the user.

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. A user can
build more convenient notations on top of that. OTOH, providing a separate
function for each optional argument can easily be overkill. 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.

Please excuse the not purely technical argumentation :-). 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 often get around such naming problems by using the module
> system and controlled use of open. [...]

Yep. The "let open DSL in ... end" idiom can be very convenient. The main
limitation (in SML) is that fixity declarations are not part of signatures.
(Which is why I've tried to find techniques to reduce the need for ad hoc
fixity declarations.)

...

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.

-Vesa Karvonen