• BluePowerEnglish
    2•3 months ago

    Also fun fact, lists on Perchance are actually made of custom objects, and so every single type of JavaScript objects is treated by the Perchance engine as “lists”. And since arrays are of objects, evaluating them directly will output a random item from the array, as if they’re lists, if you don’t know yet.

    In addition, [ ({}) ] and [ [{}] ] gives the same result as e = [ x = {} ].

    • @wthit56OPEnglish
      2•3 months ago

      Ah yes, I’ve seen perchance is everywhere… which is cool sometimes, unless you don’t want it to be perchancing and then it’s a bloomin’ nightmare. 🤣 And if you know JS as I do, and come in here thinking you can do easy things… you’re probably going to bash your head against a brick wall from time to time until you can hack your way around it!

      I could see why [({})] returns the same value as [x={}]. Shouldn’t [[{}]] return an array though? Or do you just mean in terms of it perchancing it so it gives you one of the array items at random and there’s only one array item so it (eventually evaluates to) the same thing?

  • @perchanceMEnglish
    2•3 months ago

    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 of eval 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.

    • @wthit56OPEnglish
      2•3 months ago

      Oooooh, that was why it was complaining about a “function definition” needing a name, even though it’s an assigned value. Huh!

    • @wthit56OPEnglish
      1•3 months ago

      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 the return 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?