[feature request] The interactive mode should accept incomplete statements and only execute them when they are complete

[yurivict]

There are two ways how the interactive shell can operate:

• It can execute every entered line independently
• It can wait for a complete statement to be entered across several lines, and then execute it

The mujs executable operates in the first mode: it executes lines independently.

It would be great if it would operate in the second mode. This would allow:

• Users playing with JS interactively with more complex, multi-line scripts.
• Using JS to process requests in a server/client mode. A request can have empty space, newlines in it that don't constitute the end of the statement.

[sgbeal]

FWIW, that's far, far more difficult to implement than the current mode, requiring support in both the client-side portion of the language parser/evaluator and the line-editing library used by the shell. Though i'm not familiar with mujs's client-side API, i personally have never used a scripting engine API which allows the caller to effectively ask "is this a complete or partial expression?" without evaluating the code. Without such support, it's effectively impossible to implement the 2nd approach.

i know that browser dev tools support that mode, but they also have a "much closer relationship" with the JS engine than most client-level code does.

[yurivict]

My particular use model is that I run a mujs-like executable as a "server". Its stdin is a request pipe serving JS-formated requests, just function calls, and its stdout produces responses which are just strings. As it happens, requests grow more and more complex, and can't fit in one line.

Now I need to introduce some "BREAK" token that the server would send as a label for the end of the request. So my MuJS-based code would first parse the input up until this "special" token is received, and then run the whole string.

It would have been so much nicer if MuJS could just serve such requests all by itself without having to introduce this "BREAK" token and parse the stream manually.

[yurivict]

I'm thinking if you could add a function js_maybe_dostring(J) that would be the same as js_dostring but only when the string contains a complete JS statement.

This would imply that js_has_complete_statement(J) can exist. Can JS be parsed in a LALR(1)-fashion? This project claims to do this: https://github.com/abrobston/jscc .

[sgbeal]

i don't discount the utility of it, i'm just pointing out that such a feature is (depending on the scripting engine's API) generally not trivial to implement, requiring support at multiple unrelated levels of code. It generally sounds like a simple feature to implement, but it requires that the script engine has the ability to determine, without evaluating any code, whether or not a piece of code is a complete expression. Not all scripting engines are capable of that. (That said, i have no idea whether mujs can. i don't use its JS API - just its regex code.)

[ccxvii]

Implementing this in a neat fashion is going to be more trouble than it is worth.

You can implement this in a hacky fashion by using try/catch to look for a SyntaxError with an "unexpected token.*end-of-file" error message in order to detect incomplete parses.

[gardhr]

You can implement this in a hacky fashion by using try/catch to look for a SyntaxError with an "unexpected token.*end-of-file" error message in order to detect incomplete parses.

Good idea! I did just that and it seems to be working fine. Maybe @yurivict could use something similar to this but written in C? Kind of a kludge but you get the point it's actually pretty easy to do.