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]

New Kawa features - and incompatibilities


This is a warning that I will soon check into CVS a couple of
changes that will change the Kawa language.  Some code may break
or become slower - though I've tried to avoid both.

The first big change is that the "function value" in a application
is generalized from just a Procedure to other objects as well:
  (JAVA-ARRAY INDEX)
Extract the element at the given INDEX.
  (set (JAVA-ARRAY INDEX) NEW-VALUE)
Set the element at the given INDEX.
  (TYPE ARG ...)
Equivalent to (make TYPE ARG ...), assuming TYPE is an expression
that evaluates to a gnu.bytecode.type or java.lang.Class.

Other objects will likely be supported later, including
Scheme array types, and AffineTransform (apply the transform).

When the Kawa compiler sees an aplication, it tries to figure
out the type of the "function".  If it can't, it has to defer
the decision to-run-time.  Thus some application may be trivially
slower, since there is now an extra run-time test (rather than
just a cast).

All the primitive-array-XXX macros are now deprecated - as soon
as the documentation is updated!

The other big change is that the "path expressions" discussed in
http://www.gnu.org/software/kawa/PathExpressions.html
now use colon rather than backslash.  A disadvantage is that this
further overloads the colon character. However, we were already
using the colon notation for various field and methods
operations, so using \ seemed redundant.
For example:
  (list 3 4 5):cdr:car
is equivalent to:
  (*:.car (*:.cdr (list 3 4 5)))

This is where old code might break.  The problem (which existed
before but is now likely to be worse) is that non-Kawa-specific
Scheme code uses colon as a regular symbol constituent.  So
you might a symbol named
  format:symbol-case-conv
as well as a function named format.

I believe (helped by the Kawa testsuite) Kawa will do the right thing
is almost all cases.  But please let me know of things that break.

There is a new simple mechanism for testing the quality of generated
code, by verifying that the size of a compiled method is as expected.
This was used to verify that the new operations generate optimal
code, assuming the needed type declarations are present.  It will
allow me to quick catch changes that causes us to generate worse code.
--
	--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]