This is the mail archive of the kawa@sourceware.org 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: Some other oddities


Sean Luke wrote:
On May 30, 2006, at 8:29 PM, Per Bothner wrote:

50% faster than "full, reasonably optimized Java" is quite impressive

Sorry: 1.25 to 1.5 *slower*. :-) Which for scheme is still _really_ good! Consider: python is typically almost exactly 10 times slower than Java in almost all of my work...

Is that jython or "native" python?


The speed of Kawa is probably very dependent on your style of Scheme
coding - and how well you avoid things that aren't optimized well.

2. Load order for mutually-referential simple-classes seems to be broken, or at least inconsistent in an undocumented way.

The problem is the semantics of "load". It is defined to read and evaluate the expressions in order, which means limited support for forward references.

If you *compile* a module that define two mutually references classes,
I believe that should work.

Actually, I'm failing on loading classes compiled to .class files as well.

I suggest compiling both classes at the same time: kawa -C tutoria1.scm ca.scm

java.lang.RuntimeException: class not instantiable: in load
        at kawa.standard.load.loadClassFile(load.java:48)

It can be useful to put an ex.printStackTrace() just before the re-throw.

Or (better) replace the 'new RuntimexException(...)' by
'WrappedException.wrapifNeeded(ex)'.

I also suggest avoiding load.  Use:
  (require <tutorial1>)
  (require <ca>)
Require actually imports the definitions into the *lexical* scope, and
so is much better-behaved and efficient, especially when used inside
another compiled module.

I had meant that saying (<foo>:bar baz quux) [e.g., casting baz into a <foo> class before calling] seemed to be less schemelike than saying (baz:bar quux) and letting the system fail at runtime if baz doesn't actually have a method called foo in it. Unless doing so would mean some efficiency loss I guess...

"Some" would be an understatement, since it would require using run-time reflection, instead of just an invokevirtual instruction. -- --Per Bothner per@bothner.com http://per.bothner.com/


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