Return to “Scripting & Modding”

Post

LTSL: Return Values

#1
A post from thesilverspanch just reminded me that I wanted to ask about return values: are they call-by-reference?

That is, if function_X calls function_Y, and passes parameter Z to function_Y, can I assign a new value to Z within the scope of function_X?

If so, is that new value for Z returned to function_X? Even if Z is a complex variable such as an array?

Alternately, must all information returned to a calling function be passed through a single return value?
Post

Re: LTSL: Return Values

#6
I'm still curious about this as well.

I had been thinking that an expression like (++ i), such as you might find in a for-loop, meant that the value of i was being changed in the function for which ++ was defined as an alias.

But it's since dawned on me that the result of (++ i) could just be the return value. i doesn't have to change.

So now I don't know.
Post

Re: LTSL: Return Values

#8
Im not sure (++ i) is anything like ++i from c++. As far as I can tell, the syntax seams to be (operator var1 var2 ... varN) where the operator is applied to all the vars. There isnt anything so far in Joshs code that we've seen to say if (++ i) is pre or post increment. The ++ at the beginning is just the operator that is being applied to the rest of the variables in the expression, so you could do (++ i j k) and it would increment all of them. Im kind of assuming that its a post-increment, but there is no way to tell as of yet.
Post

Re: LTSL: Return Values

#9
Parameters are passed by (non-const) reference. This makes LTSL powerful, dangerous, and simple all at the same time :D

Over the years I have gone back and forth many times on constness. Although I adhere to good-practice usage of const in C++, in my present state, I find myself largely unimpressed with the utility that it provides. Differentiating constness for purposes other than optimization has proven of little value to me over the course of writing the LT engine. Contrast that with static typing, which has proven itself worthwhile on far-too-numerous occasions. Now, when we start talking about compiler optimization, constness is a huge deal, and I have big plans for LTSL and constant analysis. But IMO that is an entirely different issue from whether the notion of actually annotating constness is useful to the user. My belief is that analysis of constness is crucial, while annotation of constness is largely unnecessary (unless we are talking about applications wherein having write-protected memory is essential to the very security of the process. This is obviously not the case with LTSL).

So the end result is that yes, functions can modify the values of their parameters in LTSL. If that value happens to be an L-value (in other words, it was passed via a variable or member of a variable), then the value will actually be modified. If the value is not an L-value, the assigment will have no lasting effect outside of the function (contrast this to c++, which (for reasons that are either arbitrary or not understood by myself) restricts pass-by-nonconst-reference to L-values).
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: LTSL: Return Values

#10
thesilverspanch wrote:Im not sure (++ i) is anything like ++i from c++. As far as I can tell, the syntax seams to be (operator var1 var2 ... varN) where the operator is applied to all the vars. There isnt anything so far in Joshs code that we've seen to say if (++ i) is pre or post increment. The ++ at the beginning is just the operator that is being applied to the rest of the variables in the expression, so you could do (++ i j k) and it would increment all of them. Im kind of assuming that its a post-increment, but there is no way to tell as of yet.
from what i know is that expressions are evaluated from the inside out, so when you have

Func( ++ i) it first increments i (executing the innermost function) and then evaluates the surrounding function.

So ++ i is pre-increment out of execution order
Post

Re: LTSL: Return Values

#12
The syntax is (function arg1 arg2 arg3 ...). So (++ i) means ++(i) and ++ is aliased to Int_Increment. So internally we are calling Int_Increment(i).

Since I don't find the return value of assignment to be a constructive endeavor, Int_Increment is void returning. So (MyFunction (++ i)) has no meaning, because (++ i) has no return type. OTOH (MyFunction (+ i 1)) is well-define, of course :)
Katawa wrote:Why was angelscript insufficient for lt?
It wasn't. But I didn't really want to script in c++ :) In the early days of the LT engine it was the first scripting engine that I integrated. At one point I had it working in the engine. But I decided that c++-based scripts were not how I wanted to go!
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: LTSL: Return Values

#13
Cornflakes_91 wrote: from what i know is that expressions are evaluated from the inside out, so when you have

Func( ++ i) it first increments i (executing the innermost function) and then evaluates the surrounding function.

So ++ i is pre-increment out of execution order
Ah! Good point! Sometimes I forget that with recursive expression calling, everything is inside-out and backwards!
Post

Re: LTSL: Return Values

#15
Also related:
http://en.wikipedia.org/wiki/Lazy_evaluation

The few lisp dialects (Common LISP, Scheme) I've looked at use lazy evaluation, so I imagine LTSL uses it, too.

In the case of

Code: Select all

for i 0 (< i 5) (++ i)
    ...
    do stuff
    ...
the condition and increment functions aren't evaluated immediately, but as needed by the for function. I never did grasp how the LISP interpreter knew how to recognize which functions should be lazy and which shouldn't. At least, not without creating a special case in the interpreter when reading a for block, but that seemed contrary to the simplicity of LISP's syntax.

Online Now

Users browsing this forum: No registered users and 7 guests

cron