Your interpretation isn’t quite right. The authors’ point in Section 4.3 is more about performance trade-offs and the fundamental role of type sharing, rather than dismissing the alternative as beyond the scope of ML.
Let me clarify the authors’ actual argument.
The Core Point: Performance vs. Opacity
The section distinguishes between two kinds of dependencies:
- Static-on-Static: A type depending on another type (e.g.,
datatype dec = VAL of identifier * Expr.exp). This is a compile-time dependency. - Dynamic-on-Static: A term (a function) depending on a type (e.g., the function
make_valhas the typeidentifier * Expr.exp -> dec). This involves a run-time component.
The authors’ main point is that you can almost always avoid direct static-on-static dependencies, but it comes at a cost: performance[cite: 432, 435].
Here’s how they explain it:
Instead of directly embedding one type within another (static-on-static), you can force all interactions to happen through function calls. In the
EXPR/DECLexample, instead of definingdecin terms ofexp, you could makedecan abstract type and provide a functionmake_valto create values of that type.
The problem is that this introduces a function call every time you need to bridge the two modules. These function calls cannot be safely inlined or optimized away by the compiler unless it has access to the underlying type definitions—the very static-on-static information you were trying to avoid.
Why This Matters for ML
So, the authors are not saying the alternative is “beyond ML’s concern.” On the contrary, they’re arguing that for a performance-conscious, statically-typed language like ML, this is a crucial issue.
The conclusion of the section is that tools for providing type equality information—like sharing specifications, translucent sums, and their own recursively dependent signatures—serve to improve performance by giving the compiler the information it needs to eliminate these mediating function calls.
In short, you can program opaquely, but you’ll pay a run-time price. The mechanisms discussed in the paper are about reclaiming that lost performance by safely sharing type information at compile-time.