The REPL

[olwmc]

For the next release of asteroid we would like just two things to work for our REPL.

• Basic Read-Eval-Print-Loop functionality
• Multi-line prompting/support

I'll try to use this discussion to bring up any major questions I have while developing 😎

[olwmc]

Thought: Expressions should be able to run directly in the REPL. This feels like basic QOL.

[lutzhamel]

I tend to disagree. REPL does not mean calculator. REPL means interactively use the language. In Asteroid expressions are not legal statements therefore they should not be able to be called directly from the repl. However, you can wrap them into legal statements,

> assert(1+1==2).

or

> load system io.
> io @print (1+1).

[olwmc]

REPL does not mean calculator

Definitely an interesting viewpoint and I understand where it's coming from. I'm wondering, though, how much not being able to easily (directly) see variable values and function outputs harms the usability of the CLI. Although I agree that Asteroid shouldn't natively support expressions as statements, the interactivity of this interface feels severely hindered if we can't get instant feedback. Especially for new learners.

After using the REPL for a little while now, I still find myself doing myvar "no, wait", load system io. io@println(myvar).

ATM supporting this isn't super necessary nor really practical to implement. Maybe, in the future, we could work on improving that ecosystem.

Thank you for your response :)

[lutzhamel]

OK. It seems that REPL sits at the intersection of Asteroid syntax and debugger. I don't use the Python REPL in the manner you seem to and perhaps most users do. So I will rely on your intuition...

Actually supporting expressions in the REPL should be very easy...all one has to do is create a flag to the parser object telling it whether it should be in statement or expression parsing mode then from the REPL you can call interp first in statement mode and if that fails call it again in expression mode...

In the parser when in expression mode the first parsing function it calls is exp and in statement mode it continues to be prog.

[lutzhamel]

This is exactly what I don't want to happen to Asteroid by supporting expressions as statements,

lutz$ python3
Python 3.8.9 (default, Oct 26 2021, 07:25:53) 
[Clang 13.0.0 (clang-1300.0.29.30)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def foo():
...     1
... 
>>> foo()
>>> 

Notice that the function definition is legal but makes no sense...

We have to make sure that the user understands that expression access at the statement level is purely a REPL supported thing...or is the above a strong enough argument not to support expressions at the statement level at all?

[olwmc]

I think that's more than reasonable, IMO. I sometimes dislike the term REPL because it only really is accurate on very small scale interactive environments. We, like many other languages, have a command line interface. There is (will be) much more going on than just read-eval-print.

Having that difference between the CLI and the language itself feels like a valid distinction to me. The utility of being able to see expression output immediately is incredibly high.

Fun fact, the above example is valid asteroid code, but very different reasons :)

[lutzhamel]

Weird, there was some sort of delay in GitHub so I didn't see your post until just now.

Ouch...oh well...see my comments below of how to actually interpret this in a reasonable manner...

[lutzhamel]

Actually, both Rust and R support expressions at the statement level with an interesting semantics: if the expression is the last statement of a function then the value computed by the expression becomes the return value of the function. Applying this semantics to the above Python program implies the following behavior,

lutz$ python3
Python 3.8.9 (default, Oct 26 2021, 07:25:53) 
[Clang 13.0.0 (clang-1300.0.29.30)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def foo():
...     1
... 
>>> foo() + foo()
2
>>> 

That might be an interesting extension to the Asteroid language.

[olwmc]

It doesn't feel particularly unnatural. I wouldn't be opposed. Adding alternatives for stuff like this can be very helpful to new users / code readability.

[olwmc]

Looking more into this, this feature is super weird!
The above example works, but

def foo(x):
    x

does not!