Single-Argument Functions and Abstraction
July 19, 2020

A single-argument function is a useful mathematical simplification, but it is not the whole story of software interfaces. Real programs move structured input through structured output.

The useful teaching point is interface shape: tuples, records, vectors, matrices, named fields, and typed data structures are not details added later. They are how a computation says what it needs and what it returns.

Programming-language noteOriginally posted 2020-07-19; expanded here around interface shape.

Article focus: single-argument functions, multiple inputs, return values, tuples, records, type shape, and abstraction.

The Constraint

Teaching everything as a single-argument, single-return function can hide the structure of the problem. In a real API, the input may be a record, tuple, vector, matrix, stream, object reference, or message. The output may have the same kind of structure.

Currying and product types can reduce many-argument functions to one-argument functions formally, but that does not remove the engineering need to name and organize the data being passed.

Why Shape Matters

An interface with multiple named inputs is not merely messier notation. It tells the caller what roles exist: source, destination, clock, limit, predicate, coordinate, gain, state, or configuration.

When that shape is hidden, the reader has to recover it from convention. When it is explicit, the computation becomes easier to inspect, test, and change.

The Teaching Point

Students should meet structured input and output early. Arithmetic, geometry, programming, physics, and data modeling all use values whose relationships matter.

The lesson is not that single-argument functions are wrong. The lesson is that abstraction begins when the shape of the data is made explicit enough to build on.