Log In  

The += operator seems to be implemented using some sort of string search and replace preprocessing. But there is a bug in there that eats the character just after the statement. Here is an example:

a=0
a+=(1)ba=42
print(a)print(ba)

I would expect this to print 1 and 42 but it actually prints 42 nil. I believe this is because the b from ba=42 is removed, thus replacing the next statement with a=42.

Edit: here are some more problems with the += operator.

This code will print 1 despite the syntax error (trailing comma):

a=0
a+=1,
print(a)

And if we add a space before the comma, this code will print 0 (the increment isn’t actually done):

a=0
a+=1 ,
print(a)

This will print 1 and nil for incomprehensible reasons:

a=0 b=0
a,
b+=1
print(a)
print(b)

Edit: yet another problem; syntax validation seems to be restricted to the first line, so this will not work:

-- This will not work
a += b +
     c

-- But this will work:
a += b
     + c

Edit: the above problem will silently create bugs, for instance:

P#43025 2017-08-03 05:35 ( Edited 2017-08-08 21:16)

Confirmed. I created a variation with a function, to make sure it was what you said, and it concurred:

function f()
 print("called f()")
end

a=0
a+=(1)xf()

> run
called f()

If I change it to 'a=a+(1)' it complains about there being no 'xf()'.

P#43033 2017-08-03 18:09 ( Edited 2017-08-03 22:12)

I think the comma issue has to do with multiple operands:

a,b=1,2
print(a)
print(b)

a,b=1
print(a)
print(b)

gives 1,2 then 1,nil (as it should)

then

a,b=0,0
a,
b+=1
,2
print(a)
print(b)

gives 1,2. (*)
which is neat, if only we could write it properly

a,b=0,0
a,b+=1,2
print(a)
print(b)

unexpected symbol near '2'

(*) edit: oops my bad. actually lua ends up with a,b=b+1,2

the only way for these operators (+ short-if) to work properly would be to have them properly added to lua's syntax. no idea how hard that would be...

P#43112 2017-08-07 06:06 ( Edited 2017-08-07 12:02)

> the only way for these operators (+ short-if) to work properly would be to have them properly added to lua's syntax. no idea how hard that would be...

I think it’s much harder to modify the Lua interpreter. PICO-8’s strategy of doing search-and-replace is valid and can work, but it has a few bugs still.

P#43113 2017-08-07 08:34 ( Edited 2017-08-07 12:34)

Pico-8 uses version 5.2 of the official Lua interpreter, so it'd be tricky, though not impossible, to extend its implementation. Pre-processing is doable but is bound to have problems if the pre-processor doesn't parse at least a subset of the Lua language to catch edge cases. (I don't know how the pre-processor works other than what we've figured out from black box testing.)

For picotool, I wrote the parser from scratch with the sole intent of parsing Pico-8 carts, so I added the additions directly to the grammar. The result is more robust parsing, but also some obnoxious edge case deviations from Pico-8's own parser. Good enough for a hobby project, but ideally I'd prefer picotool to be more accurate to P8's quirks.

(It's also getting to the point where I'd like to reuse picotool's parser for non-P8 applications, and the customizations to the grammar are in the way. shrug)

P#43125 2017-08-08 17:16 ( Edited 2017-08-08 21:16)

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2024-04-18 09:46:27 | 0.007s | Q:22