How many arguments should a function have?¶
One of the most interesting properties of the q language is that function application is itself a function. Apply takes a function on the left and a list of arguments on the right, and applies the function to the list, mapping each item of the list to the corresponding argument of the function.
Used properly, this is a wonderfully convenient feature, since functions can be designed to apply to many small, named things, which are themselves parts of a list or dictionary. Keeping the parts in a composite data structure is good for organizational reasons. Designing the function to see those parts as separate, named entities reduces code and improves readability.
For example, suppose that v
is a list of five heterogeneous items, and f
is a function which re-arranges those items.
v:(12;`xyz;"abc";1.1;10 20 30)
f:{[i;s;c;r;l] (s;c;i;l;r)}
Application of f
to v
serially maps the items of v
to the arguments of f
.
q)f . v
(`xyz;"abc"12;10 20 30;1.1)
Compare f
with the unary list functions g
and h
:
g:{x[1 2 0 4 3]} / what?
h:{
i:x 0; s:x 1; c:x 2; r:x 3; l:x 5;
(s;c;i;l;r) / why?
}
Good function design is the outcome of taking multiple perspectives on functionality:
- from within the function, we want the data already decomposed and ready for processing;
- from outside, the function is a node in a network of calculation routines, and we strive for uniformity and simplicity.
Balance these competing forces.
Design functions with meaningful arguments.