Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Variables don't persist #130

Open
iacore opened this issue Mar 18, 2022 · 8 comments
Open

Variables don't persist #130

iacore opened this issue Mar 18, 2022 · 8 comments
Labels
question Further information is requested

Comments

@iacore
Copy link

iacore commented Mar 18, 2022

how to reproduce the bug

First, have a file named test.nim:

const foo* = 1

Then: do this in inim

> import test
> var a = foo
> a
1
# now, edit `test.nim` to make foo 2
> a
2
@0atman
Copy link
Collaborator

0atman commented Mar 30, 2022

I don't quite understand the bug here, but you must remember that unlike python, there's no 'runtime' for variables to persist in.
Behind the scenes we add all typed lines to a file, and compile that file.

Can you explain more?

@0atman 0atman added the question Further information is requested label Mar 30, 2022
@iacore
Copy link
Author

iacore commented Apr 8, 2022

The example is counter intuitive, since var a = foo should set a to 1 until I change it. (see REPL of Python and Ruby)

Instead, a is changed to 2 without explicit setting a to 2.

@Sod-Almighty
Copy link

Agreed. It is counter-intuitive.

However, I believe what @0atman is saying is, whenever you type a line of code, that line is added to a source file somewhere and the source file is recompiled and executed. So every time you enter a line of code, it is literally as if you just entered all the lines, right then, in one operation.

Therefore, of course the value of a changes to reflect the value of foo; just as it would if you re-entered import test and let a = foo after the edit.

@Sod-Almighty
Copy link

Of course, this means the longer you continue at the REPL, the slower and slower compilation will become. Doesn't strike me as a particularly viable solution, to be honest.

@0atman
Copy link
Collaborator

0atman commented Aug 23, 2022

What we must remember is that there's NO compiler execution happening apart from the read loop between lines.
There's no 'runtime', there's no 'shell', there's no long-running language like in Python.

inim-repl is a best effort, given the constraints of the nim language. Any language that has no persistent runtime for variables to hang around in would behave the same.

Should we fake it to be similar to python? I'm not sure. That could cause some edge cases for people who assume nim will behave like nim.

I'd be interested to hear thoughts on the matter 😃

@Sod-Almighty
Copy link

Depends. Fake it how, exactly?

Is my assumption correct? As in, the REPL currently works like this:

Loop {
  Read a line from the user
  Append line to a temporary file (that already contains all previous lines)
  Compile and execute the temporary file
  Print the output of the execution
}

In which case, how do you avoid printing output from previous lines? Why didn't the second a in the OP's example print:

1
2

@Sod-Almighty
Copy link

Do you perhaps modify the previous lines to be unable to produce output? Like, set STDOUT to null or something until the last line is reached, then set it back?

@Sod-Almighty
Copy link

I think having a REPL that re-runs all previous commands every time you type something is a Bad Idea™. Suppose there are important commands higher up? Like file deletions or non-idempotent actions?

I think it might make more sense to let the user enter multiple lines, then type :run or something. Make it explicit.

And also have a :reset or :clear to drop all previous lines. Maybe more fine-grained control.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants