[MLton-user] currying = staging (was: Fixpoints)

Stephen Weeks sweeks@sweeks.com
Mon, 7 Aug 2006 13:06:31 -0700


I think that I've drowned my main point in a sea of other points and
your response focused on one of the minor ones (the benefit of
capturing staging in the type system).  So, I'd like to make my point
again without any distractions.


Far and away the most important benefit of the rule that I propose is
consistency.  Consistency within and across modules greatly eases
design and use of libraries, the construction of large programs, and
program development by teams.  When programming in SML, one has three
choices:

  1. Always use currying. 
  2. Always use tupling (except when staging requires currying).
  3. Make a case-by-case decision for each function.

Solely from the benefit of consistency, (1) and (2) are far superior
to (3).  If one chooses (3), one opens up the design space in a way
that will never be closed, and one will forever be having to make
decisions as to whether to tuple or curry, possibly revising the
decision later, and debating and explaining the decisions among
programmers.  By choosing (1) or (2), one makes a decision once and
for all, and saves countless hours exploring cosmetic areas in the
design space.  Further, one has a single, easy-to-remember rule that
instantly tells one about library functions and code that others have
written (or one's own code from long ago).

For other reasons, some of which I've mentioned on this thread, (2) is
preferable to (1).  But those are irrelevant to my main point.

The same consistency argument applies to choosing a convention for
argument ordering.  By choosing a convention, like the MLton
convention of always putting the object first, one is saved countless
future decisions and debate on cosmetic issues, and one can get on
with the business of programming.

Opening up both the decision of currying/tupling and the decision of
argument ordering leaves such a wide open space of cosmetic choices in
function types, which brings so many drawbacks for so little gain.



Now that I've made my main point, I'll respond to a couple of minor
ones, which are really more related to the tradeoff between (1) and
(2) as opposed to the tradeoff between ((1) or (2)) and (3).

> > It's not always useful, but it often is, and if one isn't
> > consistent, one can never convey that useful information.
...
> I disagree.  Whenever the use of staging isn't otherwise clear
> from the context or signature one can always add a comment to
> the signature.

Of course.  But the ability to use comments is no argument for not
using the type system if one can.

> > In the cases where staging is actually used in an implementation
> > it is usually very important that the client understand the
> > staging and use it correctly.
...
> Indeed.  If staging really is important it warrants a comment
> explaining why staging is used and how clients should use the
> staging.

Of course.  Comments are essential.  But it is still all the better if
the type system warns users about unusual behavior.

> The SML type-system does not prevent one from misusing a staged
> function by applying it to all arguments repeatedly.

True.  That the type system does not prevent all errors is no argument
against using it as much as possible.  If currying means staging, then
one is much less likely to misuse a staged function, and one will be
alerted by the type checker of changes in staging.