Chained slot access on BUKKITS does not work sometimes, with no error message. about lci HOT 6 CLOSED

I think this may be an issue with nested array access in the same expression. I seem to be able to reproduce the issue with

I HAS A row ITZ 0
I HAS A col ITZ 0
VISIBLE MATRIZ'Z SRS row'Z SRS col " "!

However, separately accessing the column array and then accessing an element works OK

I HAS A rowIdx ITZ 0
I HAS A colIdx ITZ 0
I HAS A colData ITZ MATRIZ'Z SRS rowIdx
VISIBLE colData'Z SRS colIdx " "!

Thanks for flagging this, I'll look into it.

from lci.

I got some additional information. The problem seems to be when you're using a variable as last element of the expression before the second 'Z:

• This works: MATRIZ'Z SRS 100'Z SRS 100
• But this doesn't: I HAS A VAR ITZ 100, MATRIZ'Z SRS VAR'Z 100
• If we add a SUM 0 this works: MATRIZ'Z SRS SUM OF VAR 0'Z 100
• But if the 0 is in a variable it doesn't: I HAS A ZERO ITZ 0, MATRIZ'Z SRS SUM OF VAR ZERO'Z 100
• But this does: MATRIZ'Z SRS SUM OF VAR DIFF OF ZERO 0'Z 100

My guess is that the interpreter doesn't know if the second 'Z should be executed before or after the first one, i.e. the two interpretations:

• (MATRIZ'Z SRS VAR)'Z 100
• MATRIZ'Z SRS (VAR'Z 100)

Which is actually unspecified I think.

from lci.

Yeah, good point, the BUKKIT proposal I used (https://web.archive.org/web/20111027063946/http://lolcode.com/proposals/1.3/bukkit2#slot-access) does not specify the precedence of direct versus indirect slot access.

It looks like lci parses code similarly to your second interpretation (the parse tree will look more like MATRIZ'Z (SRS (VAR'Z 100))). This can be seen at https://github.com/justinmeza/lci/blob/master/parser.c#L1754-L1758 which will attempt to parse the largest identifier after 'Z. There are two issues here: (1) does this behavior make sense? and (2) evaluating the expression VAR'Z 100 still should have printed out a relevant error message.

Regarding (1), I'm not entirely sure, as it really depends on defining operator precedence for 'Z relative to SRS, which is probably arbitrary, but which should be stated somewhere (in the next draft spec).

Regarding (2), I'll look into why an error message wasn't printed.

from lci.

OK, it seems that when a variable is being indexed like an array, the code was not checking to make sure the type of the variable was indeed an array and this could cause normal variables' data to be treated like pointers to ScopeObjects, which was causing some weird behavior. Going to fix this up.

from lci.

Pushed a commit that should now print an error message when a variable that is not an array is trying to be accessed like an array. The array access precedence is the same as it was before.

from lci.

You are very efficient, thanks!
What do you think about allowing using MKAY to define the precedence?

• MATRIZ'Z SRS VAR'Z SRS 100 = MATRIZ'Z SRS (VAR'Z SRS 100) = MATRIZ[VAR[100]]
• MATRIZ'Z SRS VAR MKAY'Z SRS 100 = (MATRIZ'Z SRS VAR)'Z SRS 100 = MATRIZ[VAR][100]

from lci.