Deno: REPL emits surprising output on `> {a: 1}`

[kevinkassimo]

Currently,

> {a:1}
1
>

Expected:

> {a:1}
{ a: 1 }
>

This is due to v8 considering {} as a scope instead of object.
In Node, this is solved by secretly adding a pair of parentheses around the object, like

{a:1} => ({a:1})

The code implementing this is available here:
https://github.com/nodejs/node/blob/ae73b73eeb99101188c860cce488ccc085b2f268/lib/repl.js#L235-L243

I am expecting a similar patch for this after #1407 and #1420 are landed...

[justjavac]

platform | result
------------ | -------------
Node | { a: 1 }
Chrome | { a: 1 }
FF | 1
Edge | 1

if compatible with most platforms, it should return { a: 1 }

---

in Chrome repl outputs { a: 1 }. when using devtools's watch, it output 1

---

in Node.js

> {a:1}
{ a: 1 }

> {a:1};
1

> {a:1;}
1

> {
... a: 1
... }
{ a: 1 }

> {
... a:1;
a:1;
   ^
SyntaxError: Unexpected end of input

Chrome:

> {a:1}
{ a: 1 }

> {a:1};
1

> {a:1;}
1

> {
      a: 1
  }
{ a: 1 }

> {
      a:1;
  }
1

Should we refer to chrome? @kevinkassimo

[kevinkassimo]

@justjavac Ideally we should. However, I think the behavior of Node is much easier to implement by simply introducing 2 tries, first with wrapping parentheses and second without.

On the other hand, Node internally uses acorn to do some JS parsing to determine the best handling approach. I would say we might want to keep things simpler for Deno at current stage...

[justjavac]

keep things simpler for developers

[kevinkassimo]

@justjavac Eventually we should... but we would also need better infra for that... There are still a bunch of more important improvements we need to introduce to REPL... It's more about prioritization and iterations...

[Qix-]

Yeah I mean, the fact I can't even paste a Typescript function without it puking makes the REPL kind of useless for me. I find myself _constantly_ switching back to Node and I'm only a few days into evaluating Deno.

function swap32(n: bigint): bigint {
    return ((n >> 24n) & 0xFFn) | ((n << 24n) & 0xFF000000n) | ((n & 0xFF0000n) >> 8n) | ((n & 0xFF00n) << 8n);
}


error: Uncaught SyntaxError: Unexpected token ':'
► <unknown>:1:18
    at evaluate ($deno$/repl.ts:84:34)
    at replLoop ($deno$/repl.ts:175:13)

Most of the time in the REPL I'm going to be running _expressions_ - I want to see how the engine evaluates something.

Doing hacks is not something I'd hope Deno to do, but instead looking at the AST and figuring out whether or not the input is an expression is something I think makes a lot of sense.

[kitsonk]

@Qix the issue you want is #1158 and it isn't so straight forward to support.

[Qix-]

I don't see how using an AST pass to determine the node type would constitute as "complex". I see it as "correct", however, and anything less correct than that feels like Deno cutting corners and going down a similar path that Node did.

Not the quality I expected from Deno. Might as well keep using Node at that point.

[kitsonk]

Not the quality I expected from Deno. Might as well keep using Node at that point.

Please feel free.

[kevinkassimo]

@Qix- Deno is not stable yet. It took Node many years to reach the quality today, and we cannot expect everything would suddenly miraculously work for Deno. (REPL is just one thing. There are many more things to worry about atm (e.g. strong Web spec compliance related work). Check PRs to see what is going on with the focus of the team)

Node is solid, and definitely continue use Node for very serious purposes for the time being.

Also I think Bartek is making some experiments right now (following the path of ts-node) #3760