I discovered this while trying to reduce someone's not-quite-tweetcart, and I boiled it down to a simple repro case.

These compact lines both parse and function correctly:

x+=1y-=1
y+=1x-=1

But these don't:

x-=1y+=1
y-=1x+=1

Variable names don't seem to matter. I included versions with variable names swapped just so you know it's not the variable order at fault somehow.

Same thing happens both when executing editor/app code and at the shell prompt.

I tried on the BBS and the parser here isn't able to work it either.

I didn't try other operators, like *, /, or %.

Side note: On the same subject, would you mind adding ..= and ^= operators? I think that would make the set orthogonally-complete.

..= would be awesome for strings, @Felice.

Of course putting a SPACE between x-=1 and y+=1 would fix it, but you're shooting for brevity.

Good catch on this error.

Here is a minimal repro:

x=1y+=2

PICO-8 replaces it with the following code before passing it to Lua:

x=1y = 1y + (2)

The other code works only by chance, because += replacements are performed before -=.

Cool tip:

If you want to investigate what lexical replacements PICO-8 does you can exploit the fact that it does not understand [=[ strings while Lua does:

print([=[
x+=1
if(a!=b)c()
?12,3,4
]=])

Which will print:

x = x + (1)
if(a~=b) then c() end
print(12,3,4)

@samhocevar

Huh, nice to know! I can think of many things I could have investigated if I'd know that. Thanks! :D

Ah, so now I know why this doesn't work:

x,y += 1,2

And it's because it produces this:

x,y = y + (1), 2

Which is multiple kinds of wrong. XD

@zep
It'd be awfully nice if these operators worked on tuples, because this would be a common thing in games:

vx,vy += ax,ay+9.81
px,py += vx,vy

Don't it look purty that way? ;)

Thanks @Felice, this is fixed for 0.1.12d

The preprocessor doesn't do any ast manipulation -- just hand-coded cludges that operate on each line (as you might have guessed). So things like binary operators and a,b+=c,d would add a lot of complexity without modifying the Lua parser itself, which is something I want to avoid. I do like the idea of "..=" and ^=" though, for the reason you give (orthogonally complete implies that there isn't any additional /kind/ of preprocessing going on), and added it to 0.1.12d. Ditto for "while (hoga) piyo()\n" re: your tweet, which I'm looking into now.

@samhocevar wrote:
>If you want to investigate what lexical replacements PICO-8 does you can exploit the fact that it does not understand [=[ strings while Lua does:

That is a cool tip!

I feel inclined to leave it like that; I don't think it will come up in practice, and it makes "porting" to Love etc. easier as you can wrap your whole program in a single printh[=[ ]=] to convert it to standard Lua.

Thanks, @zep! :D

> you can wrap your whole program in a single printh[=[ ]=] to convert it to standard Lua

Oo, neat, I didn't even consider doing the whole thing for that purpose. Someone with an external build chain could just spawn off a command-line run of the cart that includes the source inside and prints it back to console for easy multi-platform builds. Handy for anyone using PicoLove. Neat!