[gameprogrammer] [OT] Explicit inplace operators

(Yet another time I'm going to discuss things that are not directly=20
related to game programming, but since my project aims to be suitable=20
for game scripting among other things, and I know there's some people=20
with experience of this sort of stuff etc...)


I'm hacking away furiously at EEL, as I've been doing for a while now.=20
Since the last release (0.1.1), I've added an enum type with "recast=20
by name" (that is, they're basically lists of names in an optimized=20
form) and a rudimentary hashing string pooling engine, done some=20
general refactoring and some other stuff...

Now I'm about to add file and network I/O and that sort of stuff, and=20
it's about time to figure out a nice and clear way of dealing with=20
inplace vs "functional style" (copying) operations. This is a C style=20
language, so your average expression is on the form:

        x =3D a + b;

Now, since EEL is dynamic typed and has no (explicit) pointers,=20
objects look and act like values in the normal case. (Well, what's=20
"normal" would depend on your programming style, actually...)
Example:

        a =3D "cats";
        original_a =3D a;
        a =3D a + " and dogs";
        print a, "\n", original_a, "\n";

cats and dogs
cats

a is actually a reference to the string object "cats", but that=20
doesn't really matter here, because the + operator, as used here, is=20
non-destructive and just creates a brand new string object for the=20
result. Everything works as expected. (Well, the way *I* expect it=20
to, looking at that syntax anyway. ;-)


However nice and safe it is to work like this, it becomes very=20
restrictive when adding more interesting classes than simple strings=20
=2D like, say... AI objects in a game engine! (There; now we're almost=20
on topic. ;-) Consider this example:

        a =3D ["cats"];
        original_a =3D a;
        a =3D a + "dogs";
        print sizeof original_a, "\n", sizeof a, "\n";

1
2

('[...]' constructs an array of tagged values, indexed with integers=20
starting at zero.)

Now we have two vectors...

Well, considering the syntax of the expression, that's really what one=20
would expect, and that's the way I like it. "a =3D" means "assign=20
something to a". The expression on the right side should just deliver=20
a value; not mess with any of the operands it's supposed to *read*.=20
Of course, functions may violate this rule by doing all sorts of=20
stuff apart from generating a result.

(EEL doesn't clone objects just for the h*ll of it, so it's done by=20
the + operation rather than the 'original_a =3D a' assignment.)


Now, what if we just want to add another pet to the array, without=20
wasting cycles and generating garbage?

=46rom the VM and class implementation POV, it's trivial; just pass a=20
nil value for destination (to be overwritten by the result) for=20
copying operations, and reference to the object itself for in-place=20
operations. It's trivial to handle, and works for read-only objects,=20
operators that don't return an object instance and whatnot.

It's just that I need some syntax rules, to differentiate copying=20
oprations from in-place operations. I *don't* want to differentiate=20
operators from methods in more than one way: The former can be used=20
in infix expresions. (They need to have one or two arguments, one=20
result and they need to declare a precedence priority.)

How about this:

    Create a string:
        a =3D "";

    Destructively append "text." to a:
        a.+("text.");

    Destructively prepend "Add some " to a:
        a./+("Add some ");

That is, operator tokens can literally be used as method tokens, and=20
there's a set of reverse binary operator tokens formed by prepending=20
'/' to the normal binary operator tokens.(/+, /-, /*, //, /** etc.)

As a side effect, you could abuse the reverse operators in infix=20
expressions to come up with totally incomprehensible code, but it's=20
probably a good idea to filter that out in the parser, or even treat=20
the sequence "'/' OPERATOR" specially in the parser. Reverse infix=20
operators would just add to the set of valid combinations of=20
characters, which means a greater risk for typos getting through the=20
compiler.


Any other ideas?

=20
//David Olofson - Programmer, Composer, Open Source Advocate

=2E- 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 ---


---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html

Other related posts: