Script token precedence

[engima 328]

Consider the following script line:

_vehicle setVehicleVarName "Vehicle" + str _vehicleIndex;

My question is: How comes this works without parenthesis?

When I analyze this I cannot se why the script engine interprets this line as:

_vehicle setVehicleVarName ("Vehicle" + str _vehicleIndex);

And not:

(_vehicle setVehicleVarName "Vehicle") + (str _vehicleIndex);

The last alternative of course results in an error, since command setVehicleVarName does not return a value. If the plus (+) takes precedence we end up in the last example. So instead one could guess that the script commands take precedence. But if they would, how come only "setVehicleVarName" takes precedence over plus, but not "str"? That makes me confused.

[gulozwood 10]

hi, maybe like this:

_vehicle setVehicleVarName format ["Vehicle%1", _vehicleIndex];

[Larrow 2822]

i presume precendence order is something like

unary ops

binary ops

commands

so

_vehicle setVehicleVarName "Vehicle" + str _vehicleIndex;

+ as a binary ops has greatest precendence

+ takes two valid expressions either side of it

working left we have "Vehicle", this is a valid expressions, its a string

working right we have str, its a command so its not a valid expression on its own

so we swap to str ?, str is unary command so working right we have _vehicleIndex

str _vehicleIndex is a valid expression, and returns "1" (we will imaging _vehicleIndex holds the value 1)

we now have a valid expression to add to the right of + being str "VehicleIndex" == "1"

"Vehicle" + "1" = "Vehicle1"

So we now have

_vehicle setVehicleVarName "Vehicle1"

a command is the only thing left so it has precedence

No proof thats is how it is parsed but thats how im looking at it

[engima 328]

Thanks, that might be helpful! I'lll run some tests...

[NeoArmageddon 958]

The interpretation depends on the parser implementation for SQF. This looks like a default LL-Parser to me.

The parser looks for a series of tokens like "OBJECT COMMAND FOLLOW". The FOLLOW-token is then evaluated as it's own statement (after COMMAND is evaluated), maybe as variable, array, object, or in this case, as a concatenation of strings.

This is default behaviour of an LL-Parser and I suggest that SQF is implemented as such.

I also assume the behaviour you described above is context dependent.

But this is just guessed. Don't quote me on that.

Edited August 22, 2014 by NeoArmageddon

[Larrow 2822]

Interesting read Neo.

Never really got that heavy into the background of parsers. Think the only experience i have is from ripping through the Doom3 parser to find out why there was certain conflicts in its scripting language.

[NeoArmageddon 958]

For even more insight, I recommend reading about regular grammars: http://en.wikipedia.org/wiki/Regular_grammar

A linear parser is evaluating a regular language that can be described by an regular grammar (or something like that :D ).

Edited August 22, 2014 by NeoArmageddon