Interpreter in interactive mode: do not attempt to evaluate expression while parser says EOF

[darvin]

In[1]:= Plus[2,

Syntax::sntx: nofile:1:8: unexpected EOF, expected expression or one of ['!', '(', '+', '-', '?', ']', '{', '}', ++, --, ;;, <<, \@, \[Del], \[Integrate], \[MinusPlus], \[PlusMinus], \[Sqrt], \[Square], ]], identifier, integer, out, pattern, real, slot, string].

Desired behavior:

In[1]:= Plus[2,                                                                 

        2                                                                       
        ]                                                                       

Out[1]= 4

[darvin]

once this implemented, https://github.com/corywalker/expreduce/pull/150 probably should be reverted, because it reads in whole script completely which is aint right.

I believe we should keep eventually one code path for both interactive and batch mode:

• One code path is nice and more maintainable
• There should be possibility to read script files piped in, or very large script files

[cznic]

I think this is a regression. Could you please try to bisect?

[darvin]

@cznic https://github.com/corywalker/expreduce/commit/1c23eed951f301b7be729803329b7189eb268f3b

in expreduce.go

    for {
        rl.SetPrompt(fmt.Sprintf("In[%d]:= ", promptNum))
        line, err := rl.Readline()
        if err != nil { // io.EOF, readline.ErrInterrupt
            break
        }
        if line == "" {
            continue
        }
        fmt.Printf("\n")

line if err != nil { // io.EOF, readline.ErrInterrupt

[darvin]

i think

[cznic]

Revision https://github.com/corywalker/expreduce/commit/1c23eed951f301b7be729803329b7189eb268f3b precedes using the external parser that handles newlines differently for interactive input.

jnml@4670:~/src/github.com/cznic/wl> go run demo.go 
Enter WL expression(s). Newlines will be ignored in places where the input is not valid.
Closing the input exits the program.
In[1]:= Plus[2,

2
]
&wl.Expression{
· Case: ExpressionCase(133),
· ExprList: &wl.ExprList{
· · ExprList: &wl.ExprList{
· · · Case: 1,
· · · Expression: &wl.Expression{
· · · · Case: ExpressionInteger,
· · · · Token: INT, "2",
· · · },
· · · Token: ',',
· · },
· · Expression: &wl.Expression{
· · · Case: ExpressionInteger,
· · · Token: INT, "2",
· · },
· },
· Expression: &wl.Expression{
· · Case: ExpressionIdent,
· · Token: IDENT, "Plus",
· },
· Token: '[',
· Token2: ']',
}
In[2]:= 

[darvin]

huh it seem to be working at the time of filing this one https://github.com/corywalker/expreduce/issues/80

[corywalker]

I don't remember multi-line input ever working for the console frontend. It works very well for importing files through the "<<" operator, which is very important for loading normal source files. I did not prioritize highly multi-line support for the console frontend, which I think explains this bug.

[cznic]

I've probably created a false memory of it based on the demo program seen above. However, I think it should be easy to make multi line input work in the terminal. Just keep writing the readllines to the wl.Input until the parser accepts or rejects the input. Then run the interpreter using the resulting AST.

But I don't know enough about the internals of this project to be sure it's that simple.