I explored this here: https://perchance.org/481tgbwo1k#edit
I can’t even guess as to what’s happening with some of this. Most bizarre…
I explored this here: https://perchance.org/481tgbwo1k#edit
I can’t even guess as to what’s happening with some of this. Most bizarre…
This is correct/expected behavior, and isn’t Perchance-specific, but I’ll admit it’s confusing. It’s basically “JavaScript labelled statements strike again”. This is valid JavaScript:
{ let a = 10; x:2 }
The curly braces define a block, so that the
a
variable is only defined within that block - this is very handy, and I use it quite a lot. It’s equivalent to:if(true) { let a = 10; x:2 }
The
x:2
on the other hand is unusual and wouldn’t be written in “normal” code. It’s a labelled statement, but it’s a useless one, since there’s no way to actually “use” it.So TL;DR:
{x:2}
is being treated as a block with a labelled statement rather than a JavaScript object. The workaround is to wrap it in parentheses like[ ({ x:1 }) ]
instead of[ { x:1 } ]
.I’ve added some comments to your example generator:
b = [ {} ] // a block with nothing in it d = [ { x:1 } ] // a block with a labelled statement, x:1 e = [ x = {} ] // assignment, and so right hand side is constrained to be an expression - i.e. cannot be a block f = [ { toString: function f() { return "hey"; } } ] // same as d g = [ x2 = { toString: function f() { return "hey"; } } ] // same as e
You can test all of the above using eval like:
eval("{x:1}")
to see it’s not Perchance-specific. To add to the confusion, DevTools does some “magic” on top ofeval
in order to basically prioritize interpretation as an object, I think.I like DevTools’ approach better, and have actually considered “fixing” this, since it would be weird to use JS blocks with labelled statements inside square blocks, but it’s probably too late due to backwards-compat issues, and would need to wait for V2 of the engine.
Even though it’s not technically a bug, I’ll link this comment from perchance.org/known-bugs as something to improve on in V2 of the engine.
Oooooh, that was why it was complaining about a “function definition” needing a name, even though it’s an assigned value. Huh!
Yeah I thought it might be it getting confused about scopes vs objects again. That’s why I tried
x = {}
. Honestly, I would’ve thought it would know it’s not a scope from thereturn
you must be adding to run the code in the first place, know what I mean?Oh maybe you’re doing eval too, which doesn’t use a return–is that it? I’m still thinking in “compilation” terms, the way I do stuff like this. So the JS just stays untouched and depending on the circumstances I just wrap a
return (...)
around it. But you do a lot of eval stuff, I noticed.It’s funny, the way I’ve used eval in the past, I do the assignment in the eval. Like,
eval("x = 1")
which I guess would encourage it to see things as objects/values instead of scopes/code bodies?