Declaration of custom local variables

[x87]

Background

Currently it's possible to assign a custom name to the local variable using CONST..END:

const
  x = 0@
end

then declare a type for this variable using VAR..END or the shorter form of declaration:

int x = 5

Proposal

Get rid of the const declaration step when the shorter form of declaration is used, i.e. given an expression like:

int x = 5

the compiler should assign x to the first available local variable index (0) and compile it as 0@ = 5. then if another variable gets declared (e.g. int y = 6) it gets assigned to the next index (1), and so on:

int x   // 0@
int y   // 1@
x = y   // 0085: 0@ = 1@

Known Limitations

• the compiler is yet unable to detect if the opcode belongs to a particular script in the MAIN section (it's possible that some code in the middle of a script belongs to another script)

create_thread @a
create_thread @b

:a
int x = 0  // 0@ = 0
jump @a1

:b1
int x = 0 // 1@ = 0 error, should be 0@
end_thread

:b
jump @b1

:a1
end_thread

• there is no look-ahead for local variables so it's not possible to identify if a particular index has already been used by the scripter or not.

Conclusion

Given the limitations, for the first iteration of this feature:

• only allow the local variable declaration in a CLEO script

• always assign the first declared variable to 0@, the second one to 1@, etc. The compiler would still validate if the number of defined variables exceeds the limit for the script

• it's possible to use indexed local variables (0@, 1@, etc) and they may possibly clash with declared variables:

int x = 0
0@ = 1
wait x // wait 1

• the compiler would throw an error if both forms of local variables are used. the first used form controls (i.e. if you have 0@ in the script first you would be unable to use custom variables as described above, and vice versa)

• the documentation should clearly state that the order of variables assignment is undetermined and may change in the future (i.e. you should not assume that the first custom variable is always 0@)

[x87]

Semantic highlighting #28 should account for custom variables.

[OrionSR]

I was thinking more along the lines of including a type declaration as part of the const..end construct just so I wouldn't need to update things in two sections when I shuffle my locals around..

const
  x = 0@ : Integer
end

I've been having other issues with using constants for local variables. Sanny protests when I try to use a constant as an array. There's no problem using constants as an array index, but not to define the array in the same manner as a global variable.

Also, the type declarations of @v, or more to the point with arrays, @s wouldn't work with locals named as constants without the @. Also, for string arrays, the s would be used for assigning constant indexes, but not in the array. I've got it in my mind now that it doesn't make much sense to use constants for arrays, I should use a local or global variable instead, which is what Sanny reports.

One format that seems to make more sense:

var
  gxt_array@ = 20@ : Short
  x = 0@ : Integer
end

gxt_array@s[0] = "BLIP01"
gxt_array@s[1] = "BLIP01"

x = 1
00BA: show_text_styled GXT gxt_array@(x,2s) time 1000 style 2 

Or maybe not, but at least the example illustrates the issues nicely.

[x87]

Custom variables have been implemented. The only thing remaining is allowing them in SCM: scripts created with 004F or 00D7, missions and external scripts. This will be tracked in #284