Determine what terms input can take, fix possible issues

[alexgrejuc]

Currently, the runtime environment is not shared with input. The effect of this is that input cannot access variables or functions that are defined in the program. This may actually be a good thing, because input will always terminate (unless we allow while loops to be applied directly). It may also be confusing or annoying, however. Here is a minimal example to demonstrate this:

The program:

game G

type Input = Int

x : Int
x = 1

The REPL contents:

NOTE: this is in input mode, see my next comment below for clarification

> x

Runtime Error: "Variable x undefined"
You entered an expression of incorrect type. Please enter an expression of the correct type.

Also, that should not report as a runtime error. I suspect the front end is not typechecking the input expression.

[MartinErwig]

On Sep 22, 2020, at 9:41 PM, Alex Grejuc notifications@github.com wrote:

Currently, the runtime environment is not shared with input. The effect of this is that input cannot access variables or functions that are defined in the program. This may actually be a good thing, because input will always terminate (unless we allow while loops to be applied directly). It may also be confusing or annoying, however. Here is a minimal example to demonstrate this:

The program:

game G

type Input = Int

x : Int x = 1

The REPL contents:

x

Runtime Error: "Variable x undefined" You entered an expression of incorrect type. Please enter an expression of the correct type.

This is erroneous behavior. The type declaration should have nothing to do with it. x is a defined and well-typed name and should therefore be evaluated in the REPL.

A different question is whether x should be usable when a program encounters the command "input" to retrieve input from the REPL. I think the answer is "no", since auser of a program should generally not have access to the internal definitions of the program. (I know there are exceptions such as "play", etc.; in a better world we would have "export" declarations.)

-- Martin

[alexgrejuc]

I did not paste in the full contents from the REPL by mistake. x can indeed be evaluated, just not in input mode. Here is an example, from the same program:

> x

1

> input

 🤖 BoGL Says: Enter input, or "clear" to stop. 

> x

Runtime Error: "Variable x undefined"
You entered an expression of incorrect type. Please enter an expression of the correct type.

So, if I understood correctly, the current behavior is what you described. However, I am not sure what you mean about play as an exception. Why would a user ever need it in input mode?

[MartinErwig]

On Sep 23, 2020, at 10:34 AM, Alex Grejuc notifications@github.com wrote:

I did not paste in the full contents from the REPL by mistake. x can indeed be evaluated, just not in input mode. Here is an example, from the same program:

x

1

input

🤖 BoGL Says: Enter input, or "clear" to stop.

x

Runtime Error: "Variable x undefined" You entered an expression of incorrect type. Please enter an expression of the correct type.

So, if I understood correctly, the current behavior is what you described. However, I am not sure what you mean about play as an exception. Why would a user ever need it in input mode?

No. Scratch that.

In the REPL, all binding from the program should be accessible. Input is read as text to be parsed and converted to the expected type. No binding should be seen or served in input mode.

-- Martin

[MartinErwig]

On Sep 23, 2020, at 10:37 AM, Martin Erwig erwig@oregonstate.edu wrote:

On Sep 23, 2020, at 10:34 AM, Alex Grejuc notifications@github.com wrote:

I did not paste in the full contents from the REPL by mistake. x can indeed be evaluated, just not in input mode. Here is an example, from the same program:

x

1

input

🤖 BoGL Says: Enter input, or "clear" to stop.

x

Runtime Error: "Variable x undefined" You entered an expression of incorrect type. Please enter an expression of the correct type.

So, if I understood correctly, the current behavior is what you described. However, I am not sure what you mean about play as an exception. Why would a user ever need it in input mode?

No. Scratch that.

In the REPL, all binding from the program should be accessible. Input is read as text to be parsed and converted to the expected type. No binding should be seen or served

resolved

[montymxb]

Closing as resolved.

As a note, there is no attempt to do any typechecking or something of that kind in the frontend, this is all reported from the backend. To that end, the runtime error message will probably change when the typechecker is updated, so that may be improved along with general updates in the future.