krulwich@ils.nwu.edu (Bruce Krulwich) (11/29/89)
In article <8911272329.AA07264@garlic.Stanford.EDU>, mkatz@GARLIC (Morris Katz) writes: >For symetry reasons, a language which supports multiple return values would >require two types of arity functions: call-arity and return-arity. (Please >don't flame about the names. I just hate using foo and bar as names when I >can think of something semantically more meaningful.) Call-arity is the >procedure which is more commonly called arity and returns information about >the number of parameters which a function expect. Return-arity is the >procedure which returns information about the number of return values to be >returned by a function. I think that RETURN-ARITY is not computable in enough cases to be worth having. First of all, anytime the returned value(s) come from a call to another function, RETURN-ARITY would have to descend through the call tree. Secondly, there is no assurance that every branch of a conditional will return the same number of arguments, so there will probably be a combinatorial blowup in descending this tree. Thirdly, and perhaps most obviously, the number of values that a function returns may only be specified at run-time (such as when they come from calling a passed in procedure, or when they vary according to the number or contents of passed-in arguments), in which case it is impossible to determine RETURN-ARITY altogether. Of course, the RETURN-ARITY could be given by a programmer as a declaration of some sort, and intelligent early-binding compilers could probably use this information to make better code, but this is a seperate issue and certainly can't be assumed to exist for all functions. Bruce Krulwich Institute for the Learning Sciences