[gameprogrammer] Re: More scripting: Multiple return values

[Bob Pendleton <bob@pendleton.com>]

On Tue, 2004-04-06 at 09:17, David Olofson wrote:
> Some more questions regarding RT scripting language design;
> 
> * Does anyone have experience with game and/or real time
>   scripting with a language that support functions with
>   multiple return values?

No, not those specific kinds of languages, but I do have experience with
languages that have multiple return values and have spent a lot of time
looking at the problem of developing languages that support them. 

> 
> * Are multiple return values seriously useful? Confusing?
>   Dangerous?

They are rarely useful, very confusing, and slightly dangerous. It is
hard for a programmer to keep track of what is being returned. That is
especially true in languages with dynamic typing and a variable number
of return values. If you have static typing then the compiler can check
for type mismatches, which saves the programmer from errors. 

If you language has a vector data type then it is easy to have functions
that return variable length vectors that contain the multiple values. I
prefer to use sets with a known enumeration of values to handle
returning multiple values. The enumeration determines the possible
return values and the set, once returned can be asked for members by
name. Members that are non-existent or have a NULL value (depends on how
sets are implemented) were not returned. Or, you can a default value for
each member of the set and have the function just set the values it
wants. A function might look something like:

	function point() returns [x = 0, y = 0, z = 0, tag = "nothing"]
	{

		return x=10, y=30, tag="upper left corner";
	}

But, then assignment gets nasty:

	x, y, ..., tag = point();

The values have to be assigned in order to match the value of return
values of the function and you need a syntax to skip over values you
don't want.
 
> 
> * Does it make sense to have variable number of return
>   values?

In some cases. Once in a while I need them. In a language like C I tend
to handle them by creating a struct that contains all the return values.
In the function I have a static struct of that type. I set the values
and return a pointer to the static struct. Then I use the values or copy
them before I call the function again. I find I get few bugs from taking
the risk that the values will change than by forgetting to free() the
returned value.

> 
> * If so, which is more sensible; letting functions return as
>   many values they feel like, or letting the caller tell the
>   function how many results it should return? Or maybe ask
>   for at most N return values, and then check how many you
>   actually got?

I really think you have to declare all the values that it can return and
have a way to tag ones that didn't get returned. It is hard for me to
think of a time when you would do what you just described. The only time
I can think of is if you are returning multiple values all with the same
type. In which case you are better off just returning a vector. For
instance if you are reading from a sound stream you return a variable
length vector of samples. The vector type should have a variable or
method to return the length of the vector and an indexing function to
retrieve vales from the vector.

> 
> 
> I currently have support for multiple return values. (Functions have a 
> list of "return arguments" before the function name in declarations.) 
> There is support for variable argument count, but the result count is 
> fixed. (Hardwired at compile time.)
> 
> I also have these function references we've been discussing the last 
> few days, and obviously, these cause trouble since I can't tell how 
> many return values to make room for by looking at the function 
> declaration. :-/

The reference points to the function. If you can call a function you
have to at least know the number or arguments it takes. Therefore the
reference must point to a function descriptor. Therefore you can expand
the function descriptor to contain the full function signature including
the return values so that it can be properly executed.

> 
> A related problem is caused by the fact that I've implemented the 
> assignment operator ('=') as an actual operator. That means it's 
> handled by the normal infix expression evaluator, which in turn means 
> that I can't just look at the left hand subexpression to figure out 
> how many arguments I want, in case the right hand subexpression 
> happens to be a function call. (*If* that's actually desired, that 
> is.)

Solved above. The assignment operator can inspect the function signature
to determine what it is going to return.

> 
> 
> As usual, it's probably a good idea to decide which problems to solve 
> before starting to solve them. ;-)

In LISP... you just return a list of values if they are all the same
type or you return an associative list (which is pretty much a set).
Perl does it by returning vectors.

		Bob Pendleton

> 
> 
> //David Olofson - Programmer, Composer, Open Source Advocate
> 
> .- Audiality -----------------------------------------------.
> |  Free/Open Source audio engine for games and multimedia.  |
> | MIDI, modular synthesis, real time effects, scripting,... |
> `-----------------------------------> http://audiality.org -'
>    --- http://olofson.net --- http://www.reologica.se ---
> 
> 
-- 
+---------------------------------------+
+ Bob Pendleton: writer and programmer. +
+ email: Bob@Pendleton.com              +
+ web:   www.GameProgrammer.com         +
+---------------------------------------+