Node: Feature request: REPL show variable contents upon variable creation

[still-dreaming-1]

It would be really helpful if the node REPL would show the variable contents after creating and assigning to it. Actually this is what it does if you assign to an already created variable.

let myVar = 5
// should output 5
myVar = 10
// already does output 10

[cjihrig]

I believe this is because the REPL prints the returned value of the code it executes. In the second line of code, an assignment statement returns 10.

[still-dreaming-1]

@cjihrig You are probably right. This is a feature request to change the behavior.

[cjihrig]

I don't think that's really feasible without parsing the code to know what value to return (is it a variable declaration, assignment statement, etc.).

[still-dreaming-1]

Hmm. Well the REPL outputting anything is just because it is helpful to see that. The more helpful info the REPL can output about the code in question, the more it serves its purpose. Also it is nice when the code does not need to be altered from how it appears in a source code file for the REPL to be able to help you understand the behavior of the code. This is especially true when using a tool like codi and when using codi to run living-tests.

[Fishrock123]

I don't think parsing the code should be too difficult though, or, at least, we should just go with the common cases as a start.

I've never done a multiline variable declaration in the repl so I doubt that is common. Only thing would be parsing destructuring statements a bit.

[bnoordhuis]

I think a better solution might be to abuse the debugger and calculate the difference of variables that are in scope before and after the statement is executed. That way we don't have to be in the business of parsing JS code.

Inspecting the scope won't work for var declarations in the global scope but it will work for let and const (because those don't end up on the global object.)

[still-dreaming-1]

@Fishrock123 I appreciate any work that gets done on this. I agree with the general idea that starting with the simpler cases is better than nothing and tends to be a good way to move forward. However, I don't think it is good to reason in terms of what is common code to write in a REPL because the REPL can be used as a tool to give you an idea of how code that was not written for a REPL behaves. Codi blurs the lines between code in a file and code in the REPL. It continuously runs your code through a REPL as you type it into a file so you can get live feedback.

[lance]

I was looking at this, trying to understand what it would take to achieve it. Wouldn't this require a change to Script.runInContext and Script.runInThisContext? That's what the default REPL eval is calling, and if you follow the execution path, it looks like that function is ultimately returning the value returned from v8's Script->Run().

Thinking about this a bit more, I wonder if it makes much sense. I like that the REPL always prints the return value of an expression evaluation. When you start mucking about, trying to change what is printed in varying circumstances, where do you stop? What expression return values are OK to modify, and which are not?

There are also other considerations. For example, the printed result of this would be ambiguous, wouldn't it?

js const x = 10, y = 20, z = 30;

Should it print, 10? Or maybe 30 since that was the last assignment. It's not clear. If we were to abuse the debugger as @bnoordhuis is suggesting, I guess it might print 10,\n20,\n30\n. Maybe?

[still-dreaming-1]

@lance

When you start mucking about, trying to change what is printed in varying circumstances, where do you stop?

I think a little bit would go a long way. The problem is that as of right now, what the REPL shows you is mostly useless for code that is written in a normal way (how it appears in your source code files) except for when there are syntax errors or exceptions. It typically does not show much of anything unless you write the code differently from how you normally would, or else have syntax errors / exceptions. It would be super helpful to at least show what was returned from a function even though the return value was assigned to a variable. It is not normal to call a function and care about the return value, but then just let it disappear into the ether like you would have to in order for the REPL to show it. Either that or you have to add an extra line to make the REPL show what is in the variable. This would eliminate that.

Right now most people don't use REPLs a whole lot because they don't naturally integrate into a workflow for a task they would already have to do anyway. Most people only use them when something is funky is happening and they want the REPL to help them figure out what is going on. The more we can remove the unnecessary barriers to using the REPL the more useful it will become. Having normal code not show anything helpful in a REPL is one of those unnecessary barriers.

[Trott]

This issue has been inactive for sufficiently long that it seems like perhaps it should be closed. Feel free to re-open (or leave a comment requesting that it be re-opened) if you disagree. I'm just tidying up and not acting on a super-strong opinion or anything like that.

[still-dreaming-1]

In my opinion this feature request represents the forward progress of the entire programming industry. REPLs are important enough, and node is important enough that not having any intention to add this feature seems like a really bad idea to me. It almost makes the REPL not even a REPL if it won't even print the value of a variable after assigning it to the the value returned by a function.

[gibfahn]

I think I'd be mildly -1 on changing this. It's useful for learners (i.e. everyone) to understand what each line returns, and that's what the REPL shows you. You can do let myVar2 = myVar = 10, but you can't do let myVar2 = let myVar = 10, and if you start adding exceptions to print things that aren't returned then you lose that. You can just type myVar to see what was assigned.

❯ node
> let myVar = 10
undefined
> myVar
10
> 

I guess if it was shown differently in the REPL (e.g. Assignment: myVar = 10) then I'd be okay with it.

In my opinion this feature request represents the forward progress of the entire programming industry. REPLs are important enough, and node is important enough that not having any intention to add this feature seems like a really bad idea to me.

Node is an Open Source project. This was closed because no-one has raised a PR, and the person who chose to look at it (@lance) decided he didn't think it was a good idea. Anyone (e.g. you) is welcome to raise a PR, and several collaborators have indicated that they'd be +1 on it.

It almost makes the REPL not even a REPL if it won't even print the value of a variable after assigning it to the the value returned by a function.

IDK, quoting Wikipedia:

The print function takes the result yielded by eval, and prints it out to the user.

Seems like it's supposed to print out the returned value.

[TimothyGu]

One has to understand that this REPL behavior is implemented according to the ECMAScript spec. The spec says the following about evaluating a var a = 0; statement

VariableStatement : var VariableDeclarationList ;

1. Let next be the result of evaluating VariableDeclarationList.
2. ReturnIfAbrupt(next).
3. Return NormalCompletion(empty).

where "empty" is defined as:

When the term “empty” is used as if it was naming a value, it is equivalent to saying “no value of any type”.

So undefined seems to be appropriate here.

I'd also like to note that this behavior is also found in basically all browsers.

[still-dreaming-1]

In my opinion assigning multiple variables on one line is bad practice anyway. I don't see why the REPL should only be useful for certain types of learning when it can also be useful for the type of learning we constantly do as we are writing and testing our code.

[lance]

@still-dreaming-1 in my opinion, the REPL should be used (in part) for learning Node.js and the Javascript language. Changing the behavior so that an expression's return value appears to be something other than what the specification requires, would be a disservice to users. And if you are truly using the REPL to write and test your code, then you should expect the REPL to behave as the spec requires. And, in this case, that is that the return value of an assignment expression is undefined. This is what the language specifies, and twisting the REPL to behave contrary to the spec would be a step backwards, IMO.

[still-dreaming-1]

If it is true that the specification is such that the REPL has to work this way, well I guess I don't understand what the purpose of that part of the specification is. What were they trying to achieve and why?

[still-dreaming-1]

Having to write your code differently from how you normally would in order to get feedback from the REPL only makes the REPL less helpful and reduces its' use cases. The most helpful REPL would be one where you could write your code the same as your normally would and it still outputs helpful information, which would also open up the option to just feed it a normal code file.