ok, so this would mean: REPL mode will allow: - ...

# scripting

[apatrida]

ok, so this would mean:

REPL mode will allow:

- scripts accumulate the state of previous steps as they do now
- you must execute lines the first time in order they were compiled (previous lines must have been eval’d once)
- you can execute any line repeated times before moving on to the next line, you cannot go backwards

allowing them to execute a previous line is possible again, and it would only affect newer lines if they are also re-executed, so you could do line 1, line 2, line 1 (again), line 1 (again), line 3 (using state from old `line 2)), line 2 (again using state from newest line 1), line 3 (using state from newest line 3). This is an easy change, but not sure would confuse people, could be REPL-PLUS mode.

in Non-REPL mode:

- scripts do not accumulate, they must read/write state to somewhere made available to them if they want to pass state between evals
- scripts can execute and re-execute in any order and only side effect is based on THREADING mode (and how it isolates or doesn’t the bindings)

in JSR 223 specific version of Non-REPL mode:

- variables have to auto store to the binding, and auto read from the bindings, and this is where state would be storedbox. Compiling would have to know about the current state of bindings to be able to check things, (or generate a before/after scriptlet to read/write to bindings without checking and act like fake lines). Since Compileable interface doesn’t know about bindings if you do compile-only you can’t check anything exists or not, will wait for runtime errors. If you do eval only then you could type check based on current state of the bindings at compile time. Although bindings can change later to cause issues on script re-execution. so re-execution must read-var-from-state into variables => execute script and make $$result available => also write-vars-back-to-state This could be faked with pre/post scriptlets in between lines as a quick solution:

// renders out everything currently available in the bindings
     class Line_1_before:  Jsr223ScriptTemplate  {
             val x: Int = bindings.get(“x”) ?as Int ?: throw IllegalStateException(“binding 'x: Int' is missing from current context”)
             val y: Int = bindings.get(“y”) ?as String ?: throw IllegalStateException(“binding 'x: String' is missing from current context”)
     }

    class line_1(val line_1_before: Line_1_before): Jsr223ScriptTemplate {
          // normal stuff, it would access .x and .y from the line_1_before as-if it was a previous line and would let the compiler generate errors based on what is there or not, assuming eval() without a separate compile
         val z: String = expression...
     }

     class Line_1_after(val line_1: Line_1): Jsr223ScriptTemplate {
          init {
              bindings.put(“z”, line_1.z)
          }
     }

of course you could do it all in one class with more internal logic.