Kawa 2.0 Supports Scheme R7RS

First time accepted submitter Per Bothner (19354) writes "Kawa is a general-purpose Scheme-based programming language that runs on the Java platform. It combines the strengths of dynamic scripting languages (less boiler-plate, fast and easy start-up, a REPL, no required compilation step) with the strengths of traditional compiled languages (fast execution, static error detection, modularity, zero-overhead Java platform integration).

Version 2.0 was just released with many new features. Most notably is (almost) complete support for the latest Scheme specification, R7RS, which was ratified in late 2013. This LWN article contains a brief introduction to Kawa and why it is worth a look."

Comments

Traditional

[phantomfive]

the strengths of traditional compiled languages....zero-overhead Java platform integration

I never thought I'd hear someone say that Java integration is a traditional strength of compiled languages (especially for a dialect of a language invented in the 50s).

Re:Traditional

[phantomfive]

'Great' is orthogonal to 'traditional strength'

Re:Traditional

[Per Bothner]

Neither Java or Kawa are "traditional compiled language" in the same sense as C or C++. However, Java as a language (rather than as an implementation technology) is much closer in style to C++ than (say) Python or Ruby. Java has lexical scoping, static name resolution, ahead-of-time compilation (albeit to bytecode), does lots of compile-time error checking. In the current environment, Java (and Scala) are considered closer to "traditional compiled language" than languages like Python or Ruby, which are considered "scripting languages". Of course there is no hard distinction between the two kinds (except marketing) - and Kawa aims at the strengths of both kinds.

Re:Traditional

[Per Bothner]

"Something that I find strange is how fast kawa seems to be [even] in the repl." Note that Kawa does a full compilation (to bytecode), with all the optimizations, even in the repl. (Of course it only optimized one line/command at a time in that case.) The downside is that Kawa is a little fragile if you redefine things in the repl; hence I advise using the --no-inline option for the repl. It's on the list of things to work on when we get a chance.

Re:..that runs on the Java platform.

[DuckDodgers]

But that's the whole point. My employer does everything on the JVM for our production websites and testing. I can't get them to introduce PHP, Basic, Pascal, Ada, Perl, Haskell, OCaml, or Fortran for anything. I also can't get them to seriously consider CPython, native Ruby, SBCL (Lisp), or DrScheme.

But if I want to introduce JRuby, Jython, Scala, Groovy, Clojure, or Javascript (available in the JVM via Rhino in older versions of Java and via Nashorn in Java 7), I can get consideration.

So I suspect Kawa is an attempt to build a Scheme developers can use at work, for production, without convincing the CTO to scrap the existing JVM-based technology stack and starting over from square one. I wish them good luck. I haven't looked at Kawa yet, I'm still hoping to get my boss to look at Clojure. :)

Re:kawa

[Per Bothner]

The Kawa 0.1 interpreter from 1996 was written by Alex Milowski, who is indeed Polish-American.

I took it over in 1996, and re-wrote it as a compiler. At this point, I doubt any of Alex's code still exists. I'm Norwegian-American, and Kawa means nothing in Norwegian. Still, I saw no reason to change the name.

Re:R7RS?

[Trepidity]

Technically "The Revised Revised Revised Revised Revised Revised Revised Report on the Algorithmic Language Scheme".

Scheme was first specified in a 1975 report, which was revised in 1978. The 1978 report was called "The Revised Report on Scheme, A Dialect of Lisp". The next version of Scheme, in 1985, initiated the current trend, by naming itself, "The Revised Revised Report on the Algorithmic Language Scheme", or "R2RS" for short. Since then it functions as sort of a version number, so R3RS was the successor to R2RS, and so on. But from R3RS onward, nobody actually writes out the "Revised Revised..." part.

How does it compare to Clojure?

[Jeeeb]

The Java platform already has a major and mature Lisp-like language with Clojure. Are there any potential advantages of Kawa over Clojure or is this more of a for fun project?

Re:How does it compare to Clojure?

[Per Bothner]

Ask Rich Hickey that: Kawa (1996) is 11 years older than Clojure (2007).

The linked LWN article meantions some reasons: Among them that Kawa is much faster than closure (both execution speed and start-up speed). Plus some might like that Kawa is mostly-compatible with a pre-existing independently-specified language.

Re:R7RS?

[Bitmanhome]

The next version of Scheme ... naming itself, "The Revised Revised Report on the Algorithmic Language Scheme"

I kinda doubt the thing named itself. More likely the author named it that.

Can I have my Grammar Nazi sticker now?

Re:R7RS?

[DeVilla]

Can I have my Grammar Nazi sticker now?

Oh. You almost had it.
It's "May I ...".

Obi-Wan told Luke...

[gavron]

It's like Old Ben Kenobi told young Luke Skywalker:

"If you're trying to run it on a JVM you've already lost to the darkside."

Star Wars Quotes (that never happened)

E

Let's compare these advantages to Haskell

[ziggystarsky]

It combines the strengths of dynamic scripting languages (less boiler-plate, fast and easy start-up, a REPL, no required compilation step).

Let's see whether the great dynamic scripting language Haskell also fulfills these points.

• - less boiler-plate: in addition to not requiring type annotations, Haskell even gets rid of parens; check
• - fast and easy start-up: you can compile it to native; check
• - REPL: check
• - no required compilation step: if you use runhaskell it looks like interpreted, check (thouch technically that's a lie, as it is for JITed scripting languages

Now we see Haskell has all the advantages of dynamic scripting languages. How about the advantages of compiled languages?

with the strengths of traditional compiled languages (fast execution, static error detection, modularity, zero-overhead Java platform integration).

• - fast execution: ghc creates very efficient native code, check
• - static error detection: uhm, yes; though better than traditional languages, check
• - modularity: dunno what this means. Since there are modules in Haskell we call it check.
• - zero-overhead Java platform integration: unfortunately not. But since exactly when is Java-integration zero overhead?

Which proves that Haskell has all the advantages of dynamic scripting languages, and most of the advantages of traditional compiled languages.

Btw., you can do the same using any other modern compiled language. This post wants to show the "advantages of dynamic scripting languages" have nothing to do with the languages being "dynamic" or "scripting", whatever that means.

Re:Let's compare these advantages to Haskell

[K. S. Kyosuke]

Don't be silly. Haskell's faux-REPL is hardly comparable to the full dynamicity of Scheme or Lisp environments. You can't, for example, connect to a running process and update the code in it. The runtime simply doesn't have the facilities to update the shape of the program and its data structures, making such interesting applications as AllegroCache essentially impossible. Plus, Scheme and Lisp implementations generally include the strengths of those "traditional compiled languages" already.

Re:Parentheses

[K. S. Kyosuke]

Or, one could have a structured editor with appropriate graphical presentations. This could be awesome at least for the occasional cell phone or tablet programmer who wouldn't have to hunt for proper cursor positions if editing worked with larger meaningful units.

Re:..that runs on the Java platform.

[IQGQNAU]

OCaml has been on the JVM for a long while ( http://www.ocamljava.org/ ). Although the OSS 1.x version did go closed there is a new 2.0 version that is OSS again. Kawa was one of the earliest LISPs for the JVM and has been used by plenty of folks for almost two decades. Per invented (although I don't think patented) many of the techniques folks have been using (or rediscovering) for other languages targeting the JVM.