5

The number of parameters a function has (and thus the number of arguments it can take) is known as arity. What is the name for the number of values a function returns? I'm not asking for the "size" of a function's return values. A function returning a tuple returns a single, composite, value.

oconnor0
  • 393
  • 1
  • 8
  • What do you think it should be called? I'm fairly sure that nobody has given it a name before. – Clearer Mar 29 '18 at 22:00
  • 1
    Doesn't every function return a single value in that case? Unless you're thinking of languages such as PostScript or Polyphonic C#. – reinierpost Mar 29 '18 at 22:01
  • @Clearer I'm not sure what it should be called. "Return arity" is maybe the closest but sounds awkward. – oconnor0 Mar 29 '18 at 22:13
  • @reinierpost No, functions take multiple inputs (even though that could be mapped to a single tuple of values), and I'd like the symmetric reverse of that with functions producing multiple outputs. Hm, maybe Forth has a name for this kind of thing? – oconnor0 Mar 29 '18 at 22:16
  • Not everything under the sun has a "name". That's why we have phrases, sentences, and paragraphs -- to describe things that there's no single word for, or that there is no standard name for. – D.W. Mar 29 '18 at 22:40
  • @oconnor0 go has this feature but I'm not sure what gophers call it – slebetman Mar 30 '18 at 02:56
  • Common Lisp also has is, but I've never seen a name for it. I'm not aware of a strongly typed language that allows this and really types functions that way, except perhaps Polyphonic C# (I'd have to check). – reinierpost Mar 31 '18 at 08:38
  • Common Lisp also has it, but I've never seen a name for it. I'm not aware of a strongly typed language that allows this and really types functions that way, except perhaps Polyphonic C# (I'd have to check). – reinierpost Mar 31 '18 at 09:07

1 Answers1

9

The term "arity" would have been introduced to programming via formal logic and related fields (e.g. universal algebra). In the context of formal logic, there is little reason to allow function symbols to return multiple values even in the form of a tuple, and good reasons to disallow it. Mathematically, a function $X\to Y\times Z$ is equivalent to a pair of functions $X\to Y$ and $X\to Z$. So we don't lose anything by disallowing functions into cartesian products. What we gain, though, is a uniform syntax, especially in the context of single-sorted logic which is the typical one in formal logic.

In a single-sorted logic, there is only one sort (base type), call it $S$, so all functions are of the form $S\times\cdots\times S\to S$, or more compactly $S^n\to S$. By disallowing functions into products, if we have a term $f(x,y)$ and a function symobl $g$ of arity 2, say, then $g(f(x, y), z)$ is always a valid term. If we allowed functions into products, we'd need to at least introduce the projections $\pi_i : X_1\times X_2 \to X_i$. This would require us to assume the products were associated in some particular way or we would need to allow a whole family of projections or we would need some syntax to "spread" the results into multiple parameters. Basically, the syntax of terms would become significantly more complicated for no real gain. These syntactic complexities are reflected in programming languages that have real multi-valued returns (as opposed to just a single-valued return of a tuple).

Single-sortedness is what allows us to reduce the arity to a number. Combined with the restriction that function symbols can only return into the single sort, everything you need to know about a function symbol for the purposes of syntax can be reduced to a single number. In multi-sorted logics, it makes more sense to view the arity as a list of sorts, but since the return type is no longer fixed something more like a type annotation, e.g. $(X, Y)\to Z$, makes more sense. These type annotations are more relevant than arity. They are what you need to tell if a term is well-formed.

Most programming languages don't support a true notion of multi-valued return, and many don't even have a good notion of tuple. Occasionally in more theoretical work, the term "coarity" is used for a return sort. In a single-sorted context, the coarity could be represented by a number, but in a multi-sorted, i.e. statically typed, context it would be more natural for it to be a list of sorts. Really, computational models where operations can produce multiple outputs are usually thought of with a circuit metaphor. In such cases, we'd talk about things like fan-in and fan-out, or in-degree and out-degree.

Derek Elkins left SE
  • 12,049
  • 1
  • 29
  • 43
  • 1
    I agree with this answer, even as a Python programmer whose language has the ability for a function to "return two values". Ultimately you're just returning a tuple, which is a single thing, that just happens to involve more than one piece of information. The time where this discussion becomes more relevant is, as the author stated, in bigger-picture systems/architectures that you'd describe with a circuit metaphor! – ZachM Mar 30 '18 at 02:45
  • 1
    @ZachM go actually have multiple return values instead of just returning a single thing that contain multiple values. For example, a go function may have the prototype: func foo (someType someArg, otherType otherArg) (returnType1, returnType2) – slebetman Mar 30 '18 at 03:12
  • @slebetman I know of at least one other language that does the same (Dafny). – JAB Mar 30 '18 at 04:18
  • @slebetman: Oddly enough, I'm fairly certain Go only did that to avoid introducing (variadic) generics to the language. They wanted "returns a tuple," but tuples are too hard to implement when you don't even have fixed-arity generics, let alone variadic generics. – Kevin Mar 30 '18 at 05:14
  • You didn't need projection, the alternative is multiple assignment, like in Go. A context in which multiple return values are completely natural is stack-based languages such as Forth and PostScript. – reinierpost Apr 14 '18 at 06:10
  • Kevin, why not introduce tuple types without generics? – reinierpost Apr 14 '18 at 06:13
  • @reinierpost The "at least" is more as in "the simplest change", and not so much as in "necessary". Adding projections suffices and just involves having some "special" function symbols. Adding "multiple assignment" would require far more dramatic and complicated changes to the syntax of terms. The "spreading" I mentioned would be intermediate. Most real world programming languages already have a very complicated term syntax to which adding something like multiple assignment is usually not a big change. (On a totally different topic, without using @, Kevin is unlikely to see your comment.) – Derek Elkins left SE Apr 14 '18 at 07:10
  • @Derek Elkins: OK, but with projections, you're really just returning tuples, which seems rather pointless to me. – reinierpost Apr 14 '18 at 23:53