Strange list_get behavior

[MeWhenI]

Describe the bug Code with multiple list-gets has unpredictable effects on output.

To Reproduce Compiling

list_get (list "ABC" "123") 1;
list_get (list "DEF" "456") 1;
println (list_get (list "GHI" "789" ) 1);

with -l py produces

["ABC","123"][1]
["DEF","456"][1]
print(["GHI","789"][1])

Deleting either of the first 2 lines causes it to produce

print("789\n")

Expected behavior The lines of code before the last one should not affect how golfed the last line is. Also, note that deleting even one of the first two lines causes the other to not be outputted at all.

I suspect this may have nothing to do with the list_get op and just be about some ceiling being hit on the number of golf plugins that can be run, but at the moment I'm not sure.

[MichalMarsalek]

This is caused by a malfunctioning interpreter / hardcode plugin. We can see that Polygolf is not able to evaluate the output of the original program%3B&language=Text&objective=bytes&getAllVariants=false), but it is able to evaluate the program with one of the lines deleted%3B&language=Text&objective=bytes&getAllVariants=false), hence being able to reduce the whole program to just hardcoding the output.

[MichalMarsalek]

Ah, this is simply caused by the js output%3B&language=Javascript&objective=bytes&getAllVariants=false) not being correct javascript. The first line needs a semicolon. So this ain't a big issue, since you don't really need to use discards like this. Alternatively we can ban implicit discards outside of tests as I was considering doing several times.

https://en.wikibooks.org/wiki/JavaScript/Automatic_semicolon_insertion

3. If a line starts with one of (, [, `, +, -, or /, end the previous line with a semicolon.

This should be easy enough to fix in a detokenizer.

[MeWhenI]

No relevant cases outside of testing that I'm aware of, I just stumbled across this while testing #252

[MichalMarsalek]

We can just output single line javascript, but that would make tests slightly less readable.

[MeWhenI]

I think "semicolons only where they are strictly needed and newlines elsewhere" is a common enough golfing style to be justifiable. It trades off a bit of simplicity and consistency but maintains the readability benefits as much as possible.

[MeWhenI]

On second thought, there is at least one golf application of a statement starting with an open bracket:

[a,b]=`1 2`.split` `

[MichalMarsalek]

On second thought, there is at least one golf application of a statement starting with an open bracket:

[a,b]=`1 2`.split` `

Ok, I will patch js to replace newlines with semicolons where needed.