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

Scheme? You must be joking

[Anonymous Coward]

Rare to see anyone even thinking about that language outside the context of SICP.

Re:Scheme? You must be joking

[WarJolt]

One thing is for sure; All the scala folks are going to try it.

Re:Scheme? You must be joking

[smittyoneeach]

Haskell wept.

Re:Scheme? You must be joking

[K. S. Kyosuke]

I think you forgot SICM. ;-)

..that runs on the Java platform.

[Anonymous Coward]

'Kawa is a general-purpose Scheme-based programming language that runs on the Java platform"

Why do language designers shoot themselves in the nether regions like this? Use the Java platform, bring in all the baggage that entails, watch your language get know traction until the need to make some money diverts your interest to productive pursuits. The problem with the Java platform is any niche that can suffer under it is already filled with Java or .net.

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:..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.

Re:..that runs on the Java platform.

[DuckDodgers]

Thanks for the information. It's odd - and sad, I guess - that I heard of Clojure before I heard of Kawa (or Armed Bear Common Lisp, which as you probably already known is a Common Lisp implementation that runs on the JVM).

I have golden handcuffs at my current job, I work with some of the nicest, most professional, and especially most intelligent colleagues and managers I've had the privilege to encounter. So I'm not looking to leave soon for any reason. But most of my work is in vanilla Java, and I'm sick of it.

Re: ..that runs on the Java platform.

[ShieldW0lf]

Does this bring anything to the table that Groovy doesn't?

Re: ..that runs on the Java platform.

[Per Bothner]

"Does this bring anything to the table that Groovy doesn't?"

Yes. (I suggest reading the LWN article linked in the submission - it's fairly short.)

Re: ..that runs on the Java platform.

[DuckDodgers]

I'm guessing what you really mean with the question is, "Does this bring anything to the table that I might care about that Groovy doesn't?"

Both languages have dynamic typing. Both have a REPL. Depending upon what task you're trying to accomplish, both will let you get it done with far less syntactic overhead than Java without sacrificing readability (i.e. no crazy implicit variables or bizarre syntax shortcuts). Groovy has optional static types, while Scheme does not out of the box. On the other hand, as a member of the Lisp family Scheme has pretty easy syntax to understand, and more feature-rich macros than any non-Lisp language.

Me, I'm transitioning into a Lisp weenie as I get older, though I'm not competent enough with any dialect of Lisp to start growing my neckbeard. I like Groovy and Scheme, so I don't think you can go wrong either way. As a plus, Groovy might be an easier sell to people comfortable with Java. Getting people accustomed to C-language family syntax to try Lisp family syntax can be difficult.

Re: ..that runs on the Java platform.

[Per Bothner]

Groovy has optional static types, while Scheme does not out of the box.

However, Kawa does have optional static typing. That, plus careful language design, plus a smart compiler, means that Kawa code run very faster - much faster than Groovy or Clojure or JRuby or ...

Re: ..that runs on the Java platform.

[DuckDodgers]

Kawa has optional static types? Cool. By the way - thanks for all of your work on Kawa, it looks really neat. I'm sorry I hadn't heard about it sooner.

Re: ..that runs on the Java platform.

[Per Bothner]

Thanks. Kawa has what one might call "optimistic typing": The compiler calculates the type of an expression, and compares it with the type required by context. It only complains if this intsection is empty. In contrast, in traditional strict typing the compiler requires that expression type be a sub-type of the required type (unless there is an explicit cast). I've thought about adding an option to Kawa (it wouldn't be the default) to implement strict (sub-type) typing. However, that would require various changes and some thought to make palatable.

kawa

[blackest_k]

A Polish development by any chance? kawa being the polish for coffee, with a java base it seems likely

Re:kawa

[Anonymous Coward]

It's also the slang word for coffee in French.

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:kawa

[Trepidity]

Sort of. The first version of Kawa was by R. Alexander Miowski. He's an American, but with a pretty clearly Polish name. However the main developer has been Per Bothner since ~1996.

Re:kawa

[Trepidity]

That's "R. Alexander Milowski" with a slash on the 'l', which Slashdot ate since I guess it still doesn't support Unicode in 2014...

Re:kawa

[Anonymous Coward]

Where? I've never heard that. Maybe in some ex colony?

Re:kawa

[K. S. Kyosuke]

So basically, it's a highly polished implementation of Java?

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

[MichaelSmith]

Java has a great runtime environment. It is miles ahead of python, which is too dynamic to be optimised, even at run time.

Re:Traditional

[osu-neko]

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...

...and you didn't. The text you quoted neither says nor implies that that's a traditional strength. (In the text you quoted, the word traditional is used as an adjective modifying "languages".)

Re:Traditional

[Per Bothner]

You're off two decades: Scheme is from 1975.

Re:Traditional

[phantomfive]

Scheme is a dialect of Lisp.

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

[Anonymous Coward]

I have been trying it recently and am loving it. I am going to try to convince my boss to introduce it into our stack. Something that I find strange is how fast kawa seems to be event in the repl. Interesting indeed.

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:Traditional

[Anonymous Coward]

The whole of reality is a dialect of Lisp. Realizing it takes just a list of faith to the proofless world of the Second Order.

Re:Traditional

[K. S. Kyosuke]

That's perhaps not as silly as saying that Oberon is a dialect of Algol, but for certain meanings of the word "Lisp", it's a least somewhat misleading. Admittedly, the original comment spoke of "a dialect of a language", but when it comes to such low-level details as FFI, those inter-dialect differences could matter a great deal.

Re:Traditional

[K. S. Kyosuke]

You are aware that virtually the only thing that traditional implementations of Scheme don't have compared to Java is static type checking of variables? R7RS has lexical scoping, static name resolution, can have AOT compilation to whatever you want, the compiler already performs a lot of checks, and it's hardly a problem to extend the language to constrain the set of valid programs even further (PLT has both contracts and types, for example.)

Re:Traditional

[ray-auch]

"Great" clearly means different things to different people.

To malware authors, JRE is clearly great, because it is a frequent (successfully attacked) target. Maybe it's also great if you trust Oracle, which I don't.

Oracle's JRE patching record is not great, but worse than that you daren't set it to automatically update itself because Oracle has previously distributed malware bundled with JRE security updates ( http://www.zdnet.com/article/a... ).

R7RS?

[manu0601]

What does R7RS stands for?

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.

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 ...".

Re:R7RS?

[Anonymous Coward]

Well, unless he really _is_ curious as to whether or not he is able to...

Re:R7RS?

[Anonymous Coward]

can haz lolcatz nazi sticker?

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:How does it compare to Clojure?

[DuckDodgers]

I don't care, really - if Clojure gets more adoption or Kawa gets more adoption or both get more adoption, it's a win. Anything to make the world move towards the Lisp family is a win.

Re:How does it compare to Clojure?

[K. S. Kyosuke]

Since Kawa is an implementation of R7RS, you have the option of running your code in different implementations of the language. E.g., you might want to run your code embedded in an application or even a hardware device using Chibi Scheme. With Clojure, you're forced to either embed a JVM or use GCJ (provided that GCJ still works).

kawa rocks !!!

[Anonymous Coward]

I am working on a research project at well known institution and needed a lispy language on the jvm. Kawa was a god send for my needs and the other lispy implementations just failed horribly. Kawa was a project that I had not heard about until I needed ... kudos. It is certified platinum in my book.

why this is cool

[frobnitz]

kawa is one of the most performant dynamic language implementations on the jvm.
and it's a lisp, so it has all the advantages of that language family going for it.
the real win is the confluence of these things: a powerful dynamic language with
full access to the jvm ecosystem.

applications can run for months or years at a time with continuous hot updates.
no doubt that this is possible with other language runtimes, but i haven't seen one
that makes it easier than kawa.

compared to clojure: performance is probably the most persuasive advantage for most folks,
though for me it's that kawa is scheme

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

[Phillip2]

Pretty sure that kawa is compiled as it happens, so your distinction between haskell and dynamically typed scripting languages is false.

The parenthesis thing is a bonus for kawa, since it enables advanced syntax tree manipulation of source code both in the editing
environment, and for meta programming. And once nice feature of lisp compared to haskell is that you can do basic I/O without spending
three weeks understanding what the hell a monad is.

Re:Let's compare these advantages to Haskell

[ChunderDownunder]

since exactly when is Java-integration zero overhead?

When the organisation you're developing for is a 'Java shop'. The selling point here for Kawa over, say, Racket is that a solution can be deployed to a Java EE container.

c.f. jruby, nashorn/rhino, jython

Re:Let's compare these advantages to Haskell

[Trepidity]

A similar case is when you want to deploy to a platform-as-a-service (PaaS) provider like Heroku or Redhat OpenShift. Scheme isn't popular enough for any of these to support Scheme apps directly, but they do almost all support Java apps. So if you can deploy your Scheme app as a Java app, you can run it there.

Re:Let's compare these advantages to Haskell

[Anonymous Coward]

And once nice feature of lisp compared to haskell is that you can do basic I/O without spending three weeks understanding what the hell a monad is.

main = putStrLn "Hello, World!"

If it takes you three weeks to understand that, just give up now.

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:Let's compare these advantages to Haskell

[Anonymous Coward]

main = putStrLn "Hello, World!"

If it takes you three weeks to understand that, just give up now.

For me, it wasn't monads that sucked the fun out of Haskell. It was attitudes like this towards newbies which I saw in the Haskell community more than any other language I've worked with.

Re:Let's compare these advantages to Haskell

[Anonymous Coward]

Don't be silly. [...] Plus, Scheme and Lisp implementations generally include the strengths of those "traditional compiled languages" already.

... when ignoring that minor thing that's called static typing. I cannot understand why people make such a fuzz about this - even trying to add it to existing dynamic scripting languages, saying large code basis cannot be maintained without it. My, my, those folks apparently have never heard of unit tests.

Parentheses

[dwheeler]

Most software developers will take one look at the excessive parentheses required for Kawa and Scheme and say "nuke it from orbit". Even Lisp advocates like Paul Graham admits that syntax like "(* (+ 1 2) (- 5 4))" is painful to deal with.

Thankfully, there *are* solutions for Scheme: SRFI-105 and SRFI-110 (which I co-authored). These are extensions to Scheme that let you keep meta programming (and syntax tree editing in an editor) with readable syntax. To my knowledge Kawa doesn't implement them, but they could be added.

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:Parentheses

[Phillip2]

Yep, it's true there are times when prefix notation is painful. I got used to it years ago, though, so it doesn't really bother me any more. For maths, I agree, it confuses but it's easy to drop that, or use a threading operator for non mathematical code. And it largely absolves me from the hassle of having to think about syntax the rest of the time.

Compromises in lisp as in all things.

Re:Parentheses

[metamatic]

Semantic indentation? Blech.

If you want Python, go write Python. Don't ruin Lisp trying to turn it into Python.