This is the mail archive of the kawa@sources.redhat.com mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Defining Java Classes in Kawa


Hi Vladimir,

> >(at least for those of us who happen to know Scheme well),
> >
> IMHO I know Scheme well. Most of my projects I did in in 
> Scheme in lasts
> 6 years.

The 'us' included you, of course! ;-)

> >while interfacing with existing Java code easily.
> >  
> >
> Not agreed.
> As a general rule, avoid writing cross-language interfaces 
> unless it is absolutely necessary.

YMMV, but how many applications work in complete isolation and do not
require external libraries or access to legacy code, sometimes written in
other languages (this is particularly true in the business world)? Even in
Java, we often have to use JNI. Also, so many libraries and frameworks exist
in Java, C, C++, you can't ignore them and reinvent the wheel for each new
problem.

Of course, you don't want to go back and forth between the two languages too
often if the bridge (or FFI) is slow. But that's not the case with Kawa.

As for the OP, to me, it makes a lot of sense to develop a library/runtime
infrastructure in some language (C, C++, Java), and then provide a scripting
language based on Scheme on top of it. I've seen this numerous times, with
great success.

> Java types are statically checked, this is not true for Scheme etc.

That's not entirely correct. In Java, put an object in a container like a
hashtable, and you have to cast it back to its original type when you
retrieve it. This check is done both at compile-time AND at runtime. 

In Kawa Scheme, you can statically type all your variables if you want. But
you can omit them. Even if you type your local variables, you end up writing
less redundant code than in Java. For example:

   MyType theElement = (MyType)map.get(key);

becomes, in Kawa:

 (let ((theElement :: <MyType> (invoke map 'get key)))
    ...)

The cast is implicit instead of being explicit as in Java.

> Scheme and Java differ too much. Java is class-based, Scheme is not. 

My approach is this: use objects/classes to organize the runtime
infrastructure of your program, and use functional programming for all the
real computations. Kawa Scheme allows me to do this in the same language,
while remaining compatible with all the existing Java libraries and APIs. A
language supporting multiple programming paradigms has more expressive
power. 

Of course, the JVM is not designed for the efficient execution of
R5RS-compliant code. But that's the price I'm willing to pay for writing
code in Scheme on top of Java-based libraries.

> >and, since it's compiled to JVM bytecode, performances are 
> really good.
> >  
> >
> performances are acceptable, if you need fast code, use 
> Bigloo or Stalin.

I did not mean 'lightning fast', but fast enough for my needs. In fact, some
of my programs, written in Kawa with some type declarations, outperform the
same program but compiled with the Chicken compiler, which produces C code
(I know it does not optimize code as much as Bigloo or Stalin), with full
optimization.

>  Instant cross-platform compatibility is the key.

What do you mean by that? There is no such thing as a truly portable,
R5RS-compliant, Scheme application (I don't mean a "library", but a complete
application). Even among the major implementations, some pure Scheme code
could miserably fail due to a lack of full tail-call optimization (Bigloo,
for example).

You cannot program seriously using only R5RS Scheme. It lacks so many
features for programming-in-the-large: modules, exceptions, classes, access
to the host environment, the program arguments, etc. You have to choose an
implementation, the one that best suits your needs (supported platforms,
integration with your other techologies, etc.). You then end up writing code
that relies on the implementation.

Cheers,

Dominique Boucher



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]