@apatrida I’m sorry, but I think that changes around script definition, default args, etc., is a bit too much. This is going too deep into codebase and may interfere with other things, e.g. gradle-script-kotlin. They probably need changes, and may be your proposals are actually valid and good, but I’d like to spend more time designing and reviewing these things, and I’m pretty sure that I won’t have enough time for that before 1.1. The same is about default imports configuration. That could be a good idea, but I’d like to brew it a bit before claiming stable functionality like this. These things can go into

script-util

as long as they are clearly marked as examples of the engines/repl/scripting usage. So, if it is still acceptable for you, please prepare PR about resettable repl - this looks nice and useful. And JSR 223 state in the binding - if this could be done independently from the scriptdef changes - is also nice and useful, I believe. But please let the core stuff intact right now. We can discuss deeper changes there later.

ok, sounds good

as a side note,

gradle-script-kotlin

uses things at a lower level than these changes, but I don’t know what list of OTHER things in the world are already starting to use scripting API's

and you’re right, it has to be designed in a stable way

@ilya.chernikov I think in JSR 223 mode, no history every really builds up. I don’t see anything that doesn’t seem to make every script stand alone interacting only with bindings

REPL mode is different, it accumulates the history

I guess when the JSR 223 engine is made it could choose the mode, REPL or not

in non REPL mode, the only state that is kept is within the Bindings

wait, I do find a oracle example where they do multiple evals:

// evaluate JavaScript code that defines an object with one method
        engine.eval("var obj = new Object()");
        engine.eval("obj.hello = function(name) { print('Hello, ' + name) }");

        // expose object defined in the script to the Java application
        Object obj = engine.get("obj”);

or it isn’t really doing that.

they say that a variable declaration should auto-store to binding, so

var obj = …

is really a put to the binding of name

obj

value

…

that is why it is available in the second eval

then the `get(“obj") `works by reading the binding

and Kotlin doesn’t natively interact with the bindings.

so...

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.

@apatrida see http://www.ibm.com/developerworks/library/j-javascripting1/ - Listing 3 and below. This is not an official doc though, I didn’t found clear statement about it in the oficial docs.

The second thing - we do not have now functionality of direct integration to bindings, and this is quite some work to implement it properly, https://youtrack.jetbrains.com/issue/KT-15450

Taking it into account, I think it is safer and easier to treat JSR 223 as a proper REPL, at least for now.

reading it.

So, in that light I don’t see any need for non-REPL mode, the compiler can do it directly, and there will be an easy API for that.

Assuming we don’t expose

Compileable

separately the REPL model isn’t too far off. But with

Compileable

it would break because you don’t care about order in JSR223 like we do.

we can’t do compileable mode, which is probably ok, not sure you did before anyway

wait, it is there

compileable says you can execute many times the same thing, and in any order after compilation

that would blow up in repl mode unless you do the REPL-PLUS I mentioned

But with explicit bindings. I think that in this case we can assume that binding is not updated.

if Bindings are provided at the very start, then it is ok, but there are examples out there that set things later including from scripts

anyway, we have REPL mode now, I’m bolting it all back together

was just wondering more about REPL-PLUS being allowed or not