Improving TorqueScript

#1

Quote:Does anyone have any interest in these changes?

Yes. :)

#2 Certainly do.

#3 Hit it with a bigger hammer!

#4 Just replace it with something better :P

But your changes is a good starting point. Keep it up

#5 I am very interested in these changes, unfortunately I wont be of much help to you! But I do support your efforts! :)

#6 Keep up the great work! TorqueScript has been and will likely be a part of this engine for it's time, so why not keep making it better!

#7 If possible( I haven't spent much time in the guts code of TS, I just work with it a lot on the front end), but we should probably make vector manipulation native, instead of having to pass through Vector*() functions.

When programming and you have 2 vectors, you would think of just doing %c = %a - %b, instead of needing to crack out a extra function to do the same with VectorSub, or add, or whatever.

Also, I dunno how anyone else feels about it, but I feel equating "" to 0 would simplify some codestuffs, especially since TS variables are initialized to "" instead of 0. So if you do a check on a variable anticipating nothing, but don't check against a null string, it'll equate to true. So %a == %b, if a is "" and b is 0, they don't equate, which has caused some problems that i had to fix by going back in and creating a second check in the if statements for if %a $= "". It just kinda bulks the code sometimes.

On that note, is there any explicit reason for using $= for string comparisons?
Why not just let it discern which type of == to use based on the variables' content in question?

#8 Thanks for the interest guys. There are still a few issues I need to resolve, but I'll probably push my changes to my T3D fork within the next week or two so you can check them out.

@jeff,

Originally I was thinking of having operator overloading for types, but after some research I concluded it would have required too many substantial changes to the interpreter.

Having a separate string comparison operator ($=) is necessary due to the way comparisons are performed. Normally if you do "==" it will push the numeric value of whatever you are comparing onto a float stack and compare it. If you do "$=" it will push strings to a string stack and do a string comparison on the string value. There isn't any facility to do more generic comparisons of variables as you might find in other scripting languages.

#9 Yeah, that makes sense. I'd figured there was probably some reason or limitation for why it's set up that way, but as said, I hadn't delved into the TS guts so I wasn't positive.
If you say it's a lot of work, I'll go with your knowledge on it.

I wonder if it'd make more sense for an incorrect ==/$= conversion to return as false, instead of true though. Dunno if it's possible to force it to return false instead of true as a default for the wrong comparison, but it's sounding like that may not be easy either.

#10 I just live by the if it's numeric, use == logic... Easy and simple :D

#11

Quote:object.field = {1,2,3};

Any chance the syntax could be revised to use square brackets? That's pretty much a standard for array literals these days. I really like the feature, though! One of my favourite features from languages like Python, though, is being able to slice arrays:

> a = [1, 2, 3, 4, 5]
> print a[1:3]
[2, 3]

And from several languages, but Haskell comes first to my mind, the ability to construct ranges:

> print [1 .. 5]
[1,2,3,4,5]

On the other hand, since TS is not a general programming language, I don't know how useful these features would be. Especially when you consider the opportunity cost of expending time and effort on them instead of other things.

Huge vote for Jeff Raab's suggestion of native vector maths.

Quote:Having a separate string comparison operator ($=) is necessary due to the way comparisons are performed.

I guess Jeff's question is... can we change that? I definitely think the $= operator is a bit unfriendly. Maybe it's not so bad - after all, Javascript has two different equality operators as well (== and ===), and Lisp has nothing short of five.

One other thing I'd really appreciate is not having to use % for local variables. $ for global variables I can just about stand. But having % symbols everywhere just makes the code really ugly to read. Hopefully this would be a backwards-compatible change - a permissive enough variable naming scheme would allow % in the first character, but not require it.

#12 I'd be more interested in speed than aesthetics ...

#13 Speed then aesthetics

#14 jamesu,
I still need to integrate my changes with yours to see if it will improve speed. I have been out of the loop for a bit so I haven't really looked at it. This winter I will have more time. If you need me to look at anything shoot a note to me.

#15 @daniel,

In this case I just decided to extend the "obj.field = {1,2,3};" syntax which wasn't implemented correctly, so the {} just stuck. [] could certainly be used too.

Ranges and slices would be nice, i'll look into it but as my time is limited I cannot promise anything ;)

Removing the % $ prefixes for variables is possible, though slightly tricky. Currently TS treats words without prefixes as constant strings, e.g "echo(word);" prints "word", "echo(fudge SPC copter);" prints "fudge copter". "new (Script @ Object)(Foo){};" makes a new ScriptObject. I don't know if anyone actually uses TS like this, but stranger things have happened ;)

@steve @jimmy,

My primary interest is improving the speed, though I'm still open to adding new things provided they don't end up being a PITA to implement. Since I'm knee deep in the interpreter code now is a better time than any to suggest such things. :)

@frank,

Any assistance is appreciated.

#16

Quote:
Since I'm knee deep in the interpreter code now is a better time than any to suggest such things

Can I throw @= into the mix then? There's +=, -= etc but no @= ...and torsion doesn't complain about it so it always catches me out.


EDIT: fixed quote tags

#17 Sorry, what's that operator used for?

The other issue with dropping % and $ prefixes is object names. Defining something like 'itemdata(cat)' means 'cat' is always going to refer to the datablock. It's a lot easier to accidentally re-declare 'cat' in your code as a variable if you drop the prefixes, which would lead to all kinds of issues.
While it might be 'ugly' to have the prefixes, they're very useful at at-a-glance breakdown of what the variable is and does and helps prevent object name issues like that.

#18 Fair enough on both counts. All right, I retract my request. Creating string literals without "quotes" has always terrified me, though.

Jeff, I think Josh's suggestion would look something like this:

> %myString = "Hello, ";
> %myString @= "World";
> echo(%myString);
Hello, World

#19 In all fairness, I never use it that way. I can see why it'd do that, but honestly, I don't ever use string literals like that. If I'm using a string, I use the quotations.

As for Josh's suggestion, that actually makes a lot of sense. Cleaner than %mystring = %mystring SPC "World"; anyways.

#20 What language is @= from? That functionality would fall under += in my book, as would string1 + string2; intuitive concatination....