[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: REPL reader of multi-language

From: Nala Ginrut
Subject: Re: REPL reader of multi-language
Date: Tue, 03 Jun 2014 14:58:00 +0800

On Fri, 2014-05-30 at 08:48 -0400, Mike Gerwitz wrote:
> On Fri, May 30, 2014 at 04:25:40PM +0800, Nala Ginrut wrote:
> > It's not a problem for Ecmascript, because its statement has to be ended
> > with semicolon. So it's easier to detect the minimum compiling unit in
> > REPL. 
> ECMAScript uses semicolon insertion---semicolons are optional, but this can
> lead to ambiguities. For example:
>   function foo() {
>     return
>       { foo: "bar" }
>   }
> `foo` will return undefined, not {foo:"bar}, because it inserts a semi-colon
> after `return`; the way to get around this is to put the beginning curly
> brace of the object literal on the same line as `return`, in which case the
> expression would be completed by the closing curly brace of the object
> literal, semicolon optional.

Oh~I didn't notice that, thanks for pointing out! ;-)

> If you take a look at Node.js' REPL, you can see how it handles line
> continuations.

Thanks! I'm going to read node.js code.

> So this problem would exist for more than just Lua. But is it actually a
> problem?

I want to provide it because the original Lua REPL provide it. Anyway,
it's relative trivial in the whole compiler frontend, so I just throw
the issue here, but with lower priority at present.

>  Ctrl+D, if needed to end an expression, would represent EOF; I
> don't know if this is valid in Lua, but in ES, if an EOF (or semicolon) is
> encountered during the parsing of an expression that requires more input,
> then it is a syntax error---the compiler and REPL would handle it in the
> same way, but the REPL would just display a PS2-style prompt (which readline
> seems to do as "..." right in Guile 2.0).

Yes, the situation you described is right, the EOF shouldn't appear in
the middle of the valid code.
But what I mean is, our REPL reader don't know when to generate EOF if
you don't type it explicitly. The current parser will start to work when
it encounters EOF. So the REPL will wait infinitely till you give it an
EOF. This is the problem I'm considering to fix.
The original Lua REPL will detect if it's a valid production in the
parser which is used to decide if the current token list is a valid
chunk to be parsed. If no, it prints continue prompt, yes for evaluating
I don't know how to provide it in scm-lalr, throw & catch exceptions in
parser seems ugly.

If you use `guild compile' or `guile -c' to run the Lua code, it's OK
because it'll get EOF successfully. 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]