Add support for GraalVM languages.

[niconomaa]

Using magics, we want to support interpreting all languages supported by GraalVM.

If this works well, we want to switch to automatic language detection. #3

[JakobEdding]

Basically works with ea2a0ef

The only things left which would be nice to have for the next meeting are execution of multiline code and supporting " for strings in code cells, not just ' :D

We might be able to solve both issues using some kind of Regex escape for strings maybe. @jonashering @tomkellog

[fniephaus]

@jak-ing have you found the LOC where your "transpiled" code is executed (probably by calling eval()). Maybe it'd be better to extract magic and language selection where that eval call is and replace it with a direct Polyglot.eval() call? Example:

Somewhere in jp-kernel or probably in nel:

eval(request.code);

turns into:

magic = polyglotExtract(request.code);
Polyglot.eval(magic.language, magic.code);

This way, you can easily support multiline code and avoid the use of regexs :)

[fniephaus]

Looks like nel also has some sort of transpiler support. And this is how nel executes JS code.

[JakobEdding]

@tomkellog wanted to take over from here but here's what I found out already yesterday:

Replacing the eval() call with Polyglot.eval()

I'm in favor of this too! vm.runInThisContext replaces eval as can be seen in the example from the vm docs. So eval() is actually not used in neither jp-kernel nor nel. But I'm not sure whether it's a good idea to swap out vm.runInThisContext with Polyglot.eval() :O Is there a GraalVM equivalent to vm @fniephaus? Or maybe we can somehow call the GraalVM node binary itself instead of runInThisContext()?

Transpiler support in nel
The transpile in nel just takes the transpile defined in e.g. IJavaScript's kernel.js through the passed config (--> Kernel(config) --> Session(...)) and doesn't do much anything else as far as I can see. Also since we don't actually transpile stuff but manipulate the code execution itself I think changing the eval() mechanism as proposed by you above is a better idea.

[fniephaus]

The StackOverflow thread talks about sandboxing, so I'm guessing you are concerned about security. First, security is not a primary goal of what we want to achieve here. Nonetheless, GraalVM can sandbox languages and thus the polyglot API can be considered "secure". By default, however, I think sandboxing is disabled. Will look into this for you...
So ultimately, we could move all modifications (e.g. magic parsing) to nel and leave everything else almost as they were, right?

[niconomaa]

multi-line, choice of quotation marks and support for all Graal language works. Code is uncommited because changes affect node modules, in main.js):

function run(code) {

    let magic = '';

    if(code.startsWith('%polyglot ')){
        magic = code.split('\n')[0].replace('%polyglot ', '')
    } else {
        return vm.runInThisContext(code);
    }

    const actualCode = code.split('\n').slice(1).join('\n');

    return vm.runInThisContext(Polyglot.eval(magic, actualCode));
}

[fniephaus]

Why

return vm.runInThisContext(Polyglot.eval(magic, actualCode));

and not just

return Polyglot.eval(magic, actualCode);

?