Multiple Function Outputs? Design questions
Semantics | Home

  Background

Eidola functions -- which serve roughly the same roles as both C's functions and Java's methods -- have input and output parameters. Eidola defines both inputs and outputs in the same way: as a list of variables.

(1)

A variable has a type and a name, so an Eidola function takes a list of named and typed inputs, and returns a list of named and typed outputs.

Since the input and output parameters are all contents of the function, they must have unique names. This allow the function's parameters to behave just like local variables, with the added behavior that some (the inputs) are set to meaningful values on function entry, and the values of others (the outputs) are passed back to the caller on function exit.

A variable cannot appear twice in either list of parameters.

(2)

But it is possible for it to appear once in each. In other words, the same variable can be an input and an output. This simply means that the input value gets passed through by default.

See the semantics reference for more details.

  The Question

Is this a good idea? Are multiple function outputs really useful? Or should a function have a single anonymous output, as is the case in most other languages? The semantics would then have a rule something like this:

(3)

  Arguments Against

It's not strictly necessary. We know languages work fine without this feature, so why add it? If it's really important to return multiple values, just create a new class.

It encourages over-featureful functions. A function is supposed to do exactly one task, and it seems logical that this should give one result. Allowing multiple outputs would encourage bulky functions which try to do a dozen things at once.

It makes algorithmic semantics harder. A single return value gives a function invocation a single type, and it's easy to make it an expression. It's not clear how multiple outputs would behave in an expression. Would a programmer have to explicitly name one? Would all of them together be a list, or an anonymous class? What can you assign them to?

  Arguments in Favor

It makes a lot of sense, and is more consistent. It's so clear and simple to treat input and output parameters similarly. It removes the need for the nebulous "void" type, and makes the behavior of parameters inside a function very clear, and easily foldable into the semantics for local variables.

Expressive power is good. Languages have to trust programmers to exercise their good judgment. Programmers who want to create bulky functions will do so anyway.

Programmers have wished for it. At least Dave and I have. Granted, the situations are rare, but I sometimes end up writing a few functions to return different outputs of the same operation, or encoding multiple meanings in the same output. For example, the java method

HashMap.get(Object key) -> Object

returns null if the given key isn't in the table, and thus can't distinguish the case where the key exists and its value is null. A multiple output definition, such as

HashMap.get(Object key) -> (boolean found, Object value)

would be able to distinguish between these two cases. Of course, one can make the same distinction with HashMap.exists, so it's arguable whether the multiple outputs have a clear advantage in this case. If the map lookup is a computationally expensive operation, there is definitiely an advantage to the multiple outputs.

Here's another similar example: an infinite-precision integer package might provide the methods div and mod. In fact, these two methods are essentially the algorithm, and since it's a computationally expensive one, it makes sense to create a divmod method which performs the division and gives both the quotient and the remainder in one fell swoop. Multiple outputs would make this savings in execution time possible without requiring the creation of a DivmodResult class.

  The Verdict for Now

I like the multiple outputs, though I acknowledge the concerns are valid. We'll plug ahead with them, and if a serious problem emerges, it's possible to reconsider things.

  Design questions | Semantics | Home Copyright 2000-2001 Paul Cantrell