repl does not track locals: User-defined functions are always nil

[beakr]

I'm on OSX, and cloned down a fresh copy of Potion. Whenever I try to evaluate a function in the repl
like so:

>> add = (x, y):
    x + y string print.

>> add (1, 2)

It will always return nil. It's very strange, because if I monkeypatch (e.g. String length(): 10.), or load the built-in readline lib, it will work perfectly.

It seems native extensions will work, but not potion functions themselves.

By the way, I've running OSX Mountain Lion if that somehow makes any difference.

[gildo]

Also here on Ubuntu. :(

[jkleiser]

I think it's not only user-defined functions. If I enter "a = 1+2" in the REPL, I get the value 3 back, but if I then type just "a", I get nil.
I get this both with OSX 10.6.8 and 10.8.5.

$ bin/potion 
>> a=1+2
=> 3
>> a
=> nil
>> 

[beakr]

@jkleiser It seems as if all user-defined values are nil. It's a considerably serious issue considering it renders the language pretty unusable.

[rurban]

@beakr Only in the repl, not in scripts. The repl is similar to the debugger pretty limited yet.

[robotii]

Hi @rurban

This is due to the way the repl works.

Each line is executed as its own block/closure, with its own local variables, which go out of scope when the block has finished executing.

Any variable that doesn't start with uppercase is considered local to the block. If you use uppercase variable names, they are treated as globals, and are available to the next block that is executed.

To fix this, we would need to change the way the repl works, to execute the expression(s) contained in the block, rather than the block itself.

This would require changes to the potion_eval function, with probably a lot of other changes to surrounding code, including potion_source_compile, which will refuse to compile a bare expression.

[rurban]

yes, the repl is very limited. @robotii 's analysis is correct, eval cannot be used for the repl, or eval needs an optional env argument to track the local environment, as in a real lisp.

I'm working on it in the branch cl_eval