[Suggestion} Please add local variables to PRPL

[kajacx]

I can say, hands down, that 60% of my errors are due to the fact that PRPL doesn't have local variables, and 80% (that is not an exaggeration) of time spent of debbuging is spent on such errors.

First, what do I mean by a "local variable"? Simple: a variable that is only visible inside one function. Why is this important? In my script, I have over 20 functions, probably a half of them have a variable named xPos, yPos or list. Without local variables, I have to put prefix before everything (like "sm_xPos" or "fh_xPos") so that calling once function will not mess with the variables from another function.

However, every now and then, I forget to put that prefix somewhere, and since there is NO WARINING when reading an unset variable (really?), I ussualy spend 15 to 20 minutes trying to find the problem.

The breaking point that got me to write this post was when one such error caused the game to crash, so I had to restart it several times to finally find out that I forgot to add a pefix somewhere again. All this could be fixed if PRPL had local variables. Not to mention the code would look a bit less ugly without all the prefixes.

It doesn't have to be proper local variables that allow recursion, as that is harder to program and slower to run.

[GoodMorning]

While this looks good on the face of it, the best implementation would likely be to automate the prefixing after compiling. And, as far as my experience stretches, it is not necessary.

I will hereunder take a CRPL example, as it shares the same structure as PRPL in this respect.

Take the Sleeper, a complex CRPL construct. This did not have map-globals to work with either, but there is some very complex scripting happening there.

While I have previously had the same thought, I ended up breaking the habit of using the same names, and they became more descriptive as a result. X1 X2 and so on became OldX NewX, RedX BlueX ... or SelfX TargetX.

I have yet to encounter a situation where a list should be called List (outside of the examples on the wiki).

Good thought, but the greatest change likely to happen to PRPL at this point is additional commands.


Side note:
Crashing is a strange result, what were you doing? We may be able to help.

[kajacx]

I ended up breaking the habit of using the same names, and they became more descriptive as a result.

Good point, but I sometimes have 3 different variables for x coordinates inside one function (like currX, offX, posX), so that wouldn't quite work for me.

However I fully agree that adding PRPL function and fixing other issues (like rating of customs maps) should take priority. I will probably make my own PRPL compiler with local variables, multi-line comments and script including, so Virgil, if you are reading this, don't worry about it.

Side note response:
I was creating ships by merging other ships. The problem was that I didn't add the ships into a list, since the name of the list was wrong, which resulted into an attempt to create a 2 000 000 x 2 000 000 sized ship :D

[GoodMorning]

You have just named those variables. I know that it takes a little time. I have been scripting in a situation where I needed X and Y for two units, as well as offset and subsidiary positions for both.

But if you find that creative naming and suffixes cannot get you out of the situation, you probably need to take a step back and consider what you are doing again. This complexity is also a warning sign for inefficiency and therefore lag (or execution truncation) approaching.

Re: Aside
Ouch. I hope that V adds a sanity check to that function.