Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Java Programming

Kawa 2.0 Supports Scheme R7RS 62

Posted by timothy from the multi-lingual dept.
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."
This discussion has been archived. No new comments can be posted.

Kawa 2.0 Supports Scheme R7RS More

Kawa 2.0 Supports Scheme R7RS

Comments Filter:

  • ..that runs on the Java platform. (Score:1)

    by 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. (Score:5, Interesting)

      by DuckDodgers ( 541817 ) <(moc.oohay) (ta) (flow_eht_fo_repeek)> on Saturday December 13, 2014 @07:14PM (#48591383)
      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: (Score:2)

        by IQGQNAU ( 643228 )
        OCaml has been on the JVM for a long while ( http://www.ocamljava.org/ [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.
        • 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'

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

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

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

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

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

  • Traditional (Score:5, Insightful)

    by phantomfive ( 622387 ) on Saturday December 13, 2014 @06:59PM (#48591319) Journal

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

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

      • 'Great' is orthogonal to 'traditional strength'

      • "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... [zdnet.com] ).

    • Re: (Score:1)

      by osu-neko ( 2604 )

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

    • You're off two decades: Scheme is from 1975 [wikipedia.org].
      • Scheme is a dialect of Lisp.

        • Re: (Score:1)

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

        • 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.
    • 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 c
      • 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.)
  • What does R7RS stands for?

    • Re:R7RS? (Score:5, Informative)

      by Trepidity ( 597 ) <[delirium-slashdot] [at] [hackish.org]> on Saturday December 13, 2014 @09:10PM (#48591783)

      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.

      • 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?

  • How does it compare to Clojure? (Score:3)

    by Jeeeb ( 1141117 ) on Saturday December 13, 2014 @09:18PM (#48591799)
    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?
    • Ask Rich Hickey that: Kawa (1996) is 11 years older than Clojure (2007).

      The linked LWN article [lwn.net] 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.

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

  • Obi-Wan told Luke... (Score:4, Insightful)

    by gavron ( 1300111 ) on Sunday December 14, 2014 @01:13AM (#48592377)

    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) [about.com]

    E

  • 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

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

      • 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 [schemers.org] and SRFI-110 [schemers.org] (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 [sourceforge.net]. To my knowledge Kawa doesn't implement them, but

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

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

        • Semantic indentation? Blech.

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

    • 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: (Score:2)

        by Trepidity ( 597 )

        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.

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

Slashdot Top Deals

Whoever dies with the most toys wins.

Close