Re: What is the Development Environment of Choice for Kawa?

[Dominique Boucher <dominique.boucher@nuecho.com>]

Hello,

I'm the author of SchemeScript. Per is right. It's not actively maintained, although it's still occasionally used here at Nu Echo. The embedded Kawa is a pretty old version (7 years old!). If there is enough interest, I 
could try to upgrade it. But I'm sure there will be some syntactic/lexical elements of Kawa that will not be supported. And I can't commit to fixing those in the very short term. 

Dominique Boucher 

----- Original Message -----
From: "Per Bothner" <per@bothner.com>
To: "Rafik Naccache [TNTeam]" <rafik@tnteam.rocks>, kawa@sourceware.org
Sent: Thursday, February 18, 2016 1:57:39 PM
Subject: Re: What is the Development Environment of Choice for Kawa?

On 02/18/2016 08:18 AM, Rafik Naccache [TNTeam] wrote: 
> Hi, 
> 
> Coming from Clojure Land, I am experimenting with various scheme implementations, guile, chicken, racket,... 
> 
> As I am experimenting Kawa, I was surprised to see how this scheme can actually beat Clojure in terms of speed and elegance, and want to use it in a serious hobby project in which I have to interact with a great share of imperative Java, a setup that would make Clojure suffer... 
> 
> But then, I can't find what tool is commonly used by the community to develop Kawa: is it emacs with comint? is it slime with the little swank glue-code? maybe something else? 

Tooling is Kawa's weak spot - though its compile-time warnings and errors 
are better than most "dynamic languages" IMO. 

I'm pretty old-school, so I mostly use Emacs (mainly just editing), the REPL, 
and print statements. (Very rarely I might use jdb to track down an infinite loop.) 
OTOH I write more Java (and lately JavaScript) than I write Scheme ... 

A related weakness is connected to Kawa's strength: Kawa does a fair amount of 
compile-time optimization and inlining. This causes problems in interactive 
development: you load a function or module, and then edit it and reload it. 
Other functions that depend on the change code may no longer work. A partial 
work-around is to use the --no-inline command-line option. I do have plans 
to improve the situation, though a combination of extra indirection and 
automatic re-compilation of dependencies. 

There are various Emacs packages and/or IDE plugins that can be used. 
There is this plugin for Eclipse: https://github.com/schemeway/SchemeScript 
However, I don't think it's actively maintained, though the git repo has 
seen a few semi-recent updates. I haven't tried it recently - a status report 
would be interesting. 

There are also various Emacs packages that can be used, though I don't have 
much experience with them. 

I have been working recently on improving the Kawa repl, both using DomTerm 
and using jline2/jline3. I have some not-quite-working code - and plenty of ideas :-) 
-- 
--Per Bothner 
per@bothner.com http://per.bothner.com/