Arc Forumnew | comments | leaders | submitlogin
1 point by etal 6065 days ago | link | parent

Looks like this is the official way to put another language on top of Java:

https://scripting.dev.java.net/

(Note their subtle language that any higher-level language running on the JVM is a "scripting" language.)

I haven't worked with it, but if it handles the mapping of Javascript's type system onto the JVM, then maybe it will do the same for Arc.



1 point by almkglor 6065 days ago | link

Does it allow "script" code to be compiled down to java or jvm bytecode, or is it strictly an interpreter for the scripting language?

-----

1 point by etal 6064 days ago | link

I'm miles out of my league here, but in the interest of science I grabbed the spec, JSR-223. Here's the juice:

Introduction:

  The original goal of JSR-223 was to define a standard, portable way to
  allow programs written in scripting languages to generate web content. In
  order to do this, it is necessary to have a common set of programming
  interfaces that can be used to execute scripts in scripting engines and
  bind application objects into the namespaces of the scripts. Therefore, in
  addition to a framework for web scripting, the specification includes a
  standardized Scripting API similar to the Bean Scripting Framework. It uses
  the Scripting API to define the elements of the Web Scripting Framework.

  [...]

  There are several areas which are intentionally omitted from the
  specification:

  - The specification does not define how scripting languages should enable
    the use of Java objects in scripts, although it is assumed that the
    scripting languages implementing the specification have this
    functionality.

  - The specification does not distinguish between scripting implementations
    that compile script sources to Java bytecode and those that do not.
    Script engines that do can be used to implement the specification, but it
    is not required.

  - The specification makes no requirements of scripting languages or the
    syntax uses to invoke the methods of Java objects in the languages.

Overview:

  In this specification, a scripting engine is a software component that
  executes programs written in some scripting language. The execution is
  generally performed by an interpreter. Conceptually an interpreter consists
  of two parts: a front-end which parses the source code and produces an
  internal representation of the program known as intermediate code, and a
  back-end which uses the intermediate code to execute the program.

  The back-end of the interpreter, also known as the executor, uses symbol
  tables to store the values of variables in the scripts.

  [...]

  Scripting engines which implement the fundamental scripting interface
  defined in this specification are known as Java Script l20 Engines.
  Conceptually, a Java Script Engine can be thought of as an interpreter, but
  this may not actually be the case. For instance scripts executed by a
  single Java Script Engine may be executed internally by different
  interpreters.

Technologies:

  - Java Language Bindings – Mechanisms that allow scripts to load Java
    classes, create instances of them and call methods of the resulting
    objects.

  - General Scripting API – Interfaces and classes that allow script engines
    to be used as components in Java applications.

  The specification does not deal with issues of scripting language design or
  interpreter implementation.

So, it looks like the way you interpret, compile and execute the code is your own business, but if your own ScriptEngine implementation matches the specified API, it will work with existing Java tools and frameworks, particularly for the web. It's modeled after Rhino, so some parts of the Rhino back-end might be directly reusable.

-----