[IPython-dev] IScala: a Scala-language backend for IPython

[Fernando Perez]

Hi Mateusz,


On Sun, Sep 8, 2013 at 12:54 PM, Mateusz Paprocki <mattpap at gmail.com> wrote:
> Hi,
>
> I would like to announce IScala: a Scala-language backend for IPython,
> see [1]. Scala is general purpose, object-functional, statically typed
> programming language for JVM. IScala is an early work in progress, but
> it's already fairly usable. All three types of frontends are
> supported. Required dependencies are IPython 1.0+ and Java Runtime
> Environment 1.6+. See README.md for installation and usage details.

This is great! Just last week I was playing a bit with Scala, this
will make my life much easier :)

> Motivation for this project came when I saw IJulia announcement. The
> hard part - actually "interpreting" Scala - was done in Scala REPL by
> Scala developers. Scala is a compiled language, so interpreting it
> means that source code is compiled (with some fancy wrappers),
> resulting class files loaded into JVM and code run via Java
> reflection. Interpreted code behaves exactly the same as compiled code
> and it runs at full speed. There are a few issues with this, however.
> Scala is a pure object-oriented language, so at top level you can put
> only packages, traits, classes and singleton objects. No expressions
> and other types of statements are allowed. Interpreter removes this
> restriction, by wrapping source code in singleton objects, so that you
> can simply write e.g. `val x = 1` to define a value, which is
> otherwise illegal.

Very interesting: I've been thinking precisely about this problem in
the context of creating an IPython kernel for Go, and wondering what
it would take.  Go doesn't have the hardcore OO stance of the JVM, but
some similar issues regarding persistence of state and compilation
arise. The lessons you've learned here would likely be very useful.

> During development of IScala I also created a set of notebooks with
> Scala code, see [2]. Those are based on a subset of Twitter's Scala
> lessons [3]. I didn't encode notebooks directly in the JSON-based
> format, but I invented an adhoc format based on Markdown with support
> for cells. There is a simple converter that allows to generate
> IPython-compatible notebooks.

I would recommend using the 'real' IPython notebook format as your
default, so that you can benefit automatically from the entire rest of
our machinery (nbconvert, nbviewer, etc).

Our long term view is for the format to be completely language
agnostic, so we're willing to make any changes and fixes to the
underlying format to accomodate Scala cleanly.  We're already looking
at a bunch of such fixes for Julia, and having another language at
hand will help us correctly identify the right abstraction points and
how to leave generality in the base format while allowing each
language to represent its own information with all the detail and
precision desired.

Cheers,

f