[gameprogrammer] Re: More scripting: Multiple return values

[David Olofson <david@olofson.net>]

On Thursday 08 April 2004 19.22, Bob Pendleton wrote:
> On Thu, 2004-04-08 at 06:08, David Olofson wrote:
> > On Wednesday 07 April 2004 01.07, Bob Pendleton wrote:
> > [...]
> >
> > > > There will be a real vector type eventually, possibly
> > > > replacing the lightweight LIST type, so it seems logical to
> > > > just use that instead when you *really* want multiple return
> > > > values.
> > >
> > > I would just go with that. But, consider adding an associative
> > > vector. One that can be indexed with strings as well as
> > > numbers. It is really nice to be able to write x =v["x"].
> >
> > Yep, that's planned as well. However, then I'll have two kinds of
> > vectors - unless I just implement index by string as an extra
> > feature of the vector type... That should be doable without
> > significant overhead when indexing with numbers, right?
>
> If you implement vectors using something like an extendable hash or
> a B tree, any indexing structure with good look up and insertion
> performance, then there is little overhead. But, it will always be
> much slower than a C style vector and it will use more memory. Of
> course, you get dynamic sizing, bounds protection, and a very
> versatile data structure.

Yeah, and that's what I want... After all, it's a scripting language; 
not a number crunching language. It's important to have some nice and 
powerful high level data types. "Fast vectors", vector operators and 
stuff might come later, but for now, I'll plug in C code for that 
kind of stuff. (Maybe opaque user datatypes or something, so 
applications can throw in custom datatypes with native operator 
code.)


[...]
> > OTOH, if functions return at most one value, this problem goes
> > away, since the result of calling a function is identical to that
> > of executing an operator opcode. :-) That's why I made "=" a
> > normal operator in the first place - but then I got this
> > brilliant idea of multiple returns... *hehe*
>
> Ah, the dangers of green field design! :-) The fewer constraints on
> the designer the more chance to wander off in never never land...
> :-) Been there, done that, and I still have the scars.

Yeah. I should be more careful to solve only the problems I *really* 
need to solve. :-)

Fortunately, it's not too late to drop the silly stuff this time, and 
things are looking fine. I'm on a tight schedule here, so I'd better 
not have too many "bright" ideas in the next few weeks! *hehe*


[...assignments; to return or not to return...]
> > Whether or not it returns a value can be changed very easily.
> > I've decided to not have it return a value for now, in order to
> > avoid the C/C++ "if(a = b) ..." problem.
>
> That is the answer I prefer...

I've had more trouble with that feature in C and C++ than with the 
lack of it in Pascal, so it seems like the best answer to me. I guess 
you could sort of have both with some fancy syntax tricks, but I 
don't really see the point...


[...]
> > Well, I just set a flag "NORESULT" when registering the "="
> > operator, which makes the expression rule return a special error
> > code that some rules trap. That way I can have C style ++ and --
> > operators and stuff that may or may not be used as
> > subexpressions, depending on what mood I'm in. ;-)
>
> I hope you are in a good mode!

Oh, let's pray things work out well - or I'll throw in a compiler 
directive that allows coders to have it their way, on a per-module 
basis! ;-D


//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 ---