New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make Scala JSR 223 compliant #874

Closed
scabug opened this Issue May 9, 2008 · 13 comments

Comments

Projects
None yet
2 participants
@scabug
Copy link

scabug commented May 9, 2008

Currently, to use Scala as a scripting engine, one has to do:

import scala.tools.nsc.*;
Interpreter n=new Interpreter(new Settings());
n.bind("label", "Int", new Integer(4));
n.interpret("println(2+label)");
// didn't event try to check success or error
n.close();

It would be nice if one could do instead:

import javax.script.*;
ScriptEngine e = new ScriptEngineManager().getEngineByName("scala");
e.getContext().setAttribute("label", new Integer(4), ScriptContext.ENGINE_SCOPE);
try {
    engine.eval("println(2+label)");
} catch (ScriptException ex) {
    ex.printStackTrace();
}

Plus, as was pointed elsewhere, the compiler used in the background by the interpreter should not need a filesystem (for instance if scripting is to be used on handheld devices etc.)

@scabug

This comment has been minimized.

Copy link

scabug commented May 9, 2008

@scabug

This comment has been minimized.

Copy link

scabug commented May 9, 2008

@lexspoon said:
I didn't know about JSR 223 before. It would be good to supply Scala as a Java scripting engine if possible.

However, there is a question about whether it can pratically be done. Interpreter.bind takes a type as an argument. The setAttribute() call in the example code does not. Is there another setAttribute() call that could be used to pass in a type? If not, it requires some deep though to figure out how to get Scala to fit into what JSR 223 expects. Treating label as type "Any" is unkikely to give a good scripting experience.

By the way, if you want to know whether an interpret attempt succeeds when using Interpreter.interpret(), simply look at the return value.

@scabug

This comment has been minimized.

Copy link

scabug commented May 10, 2008

@rjolly said:
I don't think there is a way to specify the type, so Any seems unavoidable:

http://java.sun.com/javase/6/docs/api/javax/script/ScriptContext.html

void setAttribute(String name, Object value, int scope)

Hence, there is a type unsafety in this scripting interface, but I think it is by design : all scripts don't have the same type system (as Java).
Regarding the return value, it is easy to say in Scala, but how do you code in Java:

    interp.interpret("ret(0)="+str) match {
      case InterpreterResults.Success => ret(0) toString
      case InterpreterResults.Error => "error"
      case _ => ""
    }

? Beside, what would be useful is if the interpret(str) method could return not just a success flag, but the whole evaluation of the expression (when the input statement is an expression), as is the case with ScriptEngine.eval(str). That way, one wouldn't have to use a reference object to pass it, like ret, above.

@scabug

This comment has been minimized.

Copy link

scabug commented May 13, 2008

@dragos said:
Lex, would you like to take care of this one?

@scabug

This comment has been minimized.

Copy link

scabug commented May 17, 2008

@lexspoon said:
Jim White and I have put together some minimal 223 support, just enough to work for Wings. I am currently talking with him about getting it into the main Scala distribution. The current implementation is here:

http://ifcx.svn.sourceforge.net/viewvc/ifcx/thirdparty/scripting/engines/scala/src/org/ifcx/scripting/scala/

@scabug

This comment has been minimized.

Copy link

scabug commented Jan 14, 2009

@odersky said:
Milestone next_bugfix deleted

@scabug

This comment has been minimized.

Copy link

scabug commented Feb 1, 2009

Mateusz Fioka (mateusz.fiolka) said:
I have looked at the icfx project on sourceforge and it looks very similar to the project I have found on http://code.google.com/p/netgents/ It is also a JSR-223 implementation for Scala, but writtern in Scala. If I have found the icfx page before then I would make the improvements for this version. However, before this, I sent some patches to the netgents project author to make more JSR-223 compliant. Maybe some of this code could be used to improve also the icfx project. I currently have no time to integrate it, but maybe someone could make it.

My approach for discovering types is simple:
value.getClass.getName
There are at least two catches:

  1. Specifying types in the form value:type as it was before is still useful, as sometimes script need some interfaces rather then implementations i.e. in Java List list = new ArrayList();\
  2. If we bind value 1 to some variable name it gets boxed to new Integer(1), current Scala interpreter shows deprecation warning when it encounters such value. new Integer(1) + 2 in Scala doesn't work. This is why basic types mapping is needed i.e. java.lang.Integer => Int and int => Int. When value is bound to intepreter using type Int and real value Integer(1) interpreter doesn't complain and value is passed correctly.

I have also added some code to make the script use scriptResult variable rather then result(0) because it looks perlish/magical

The project I mention also has some junit tests that I wrote which should work with any jsr223 implementation for Scala. It also could be useful to integrate it with the icfx project.

If there are some downsides related to the way I did the type bindings, then I would happily like to hear about them.

@scabug

This comment has been minimized.

Copy link

scabug commented Dec 30, 2009

michid4 said:
I implemented a Scala scripting engine a while ago for the Apache Sling project (http://sling.apache.org/). The source is here: http://svn.apache.org/repos/asf/sling/trunk/contrib/scripting/scala/

  • Runs inside an OSGi container. That is, the compile time classpath considers classes provided by the OSGi environment.

  • Each script is also a standalone Scala source entity. This leverages existing tools like IDEs and unit test suites. Of course it adds a little bit of extra burden on the script author.

  • Script bindings are visible on all its accessible interfaces. This is done by generating appropriate implicit conversions at compile time. See https://issues.apache.org/jira/browse/SLING-1236 for details.

Currently I'm working on untangling the scripting engine from Sling. My aim is to make it as versatile as possible. That is, it should run within/without OSGi and should be of course independent from Sling (or any other framework).

@scabug

This comment has been minimized.

Copy link

scabug commented Jan 6, 2010

michid4 said:
Initial progress here: https://issues.apache.org/jira/browse/SLING-1274

@scabug

This comment has been minimized.

Copy link

scabug commented Mar 4, 2011

@scabug

This comment has been minimized.

Copy link

scabug commented Mar 4, 2011

michid4 said:
Replying to [comment:18 SethTisue]:

there's this: http://my.opera.com/zilti/blog/use-scala-as-a-jsr-223-scripting-language
(though I haven't tried it)

That's the same on I mentioned here: https://lampsvn.epfl.ch/trac/scala/ticket/874#comment:11

@scabug

This comment has been minimized.

Copy link

scabug commented Dec 4, 2012

@retronym said (edited by @SethTisue on Sep 8, 2015 6:49:01 PM UTC):
This is currently out of scope for the Scala team. We don't see much demand for JSR-223; if there was a community library could fill the gap.

@scabug

This comment has been minimized.

Copy link

scabug commented Mar 12, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment