Kawa proposed typing changes

[Per Bothner <per at bothner dot com>]

Here are some changes that I'm experimenting with,
that would improve Kawa type inference, and thus
performance, and possibly compile-time error-detection.
However, they can (and probably will) break some programs.

(1) A top-level define will become writable only in the
current "module".  I.e. you can set! it in the current
source file, but not in other source files.  This will
not (at least for now) apply to the "interactive" mode
(i.e. the repl, eval, load) when forms are read one
at a time, because of the behavior/implementation of
the "top-level".

Motivation: Better type-inference.  If we know no external
module can modify a define, then we have a change to figure
out its type from the set of initialization and assignments
that we *see*.   This is compatible with R6RS libraries, which
is even stricter: If a variable is exported, no set! are
allowed even in the defining library.

Workaround:  Use define-variable rather than define, to force
the variable to be "dynamic".

(2) A module compiled with --main will by default not export
anything.  I.e. there will be an implicit:
   (module-export)

Motivation: The compiler can inline or remove unused variables.
Top-level macros can be used at compile-time, but need not be
written out into the generated class file, which means the
class can be run under "kawart.jar".  Variables could
be compiled to local variables, which can be accessed faster
than field can be.

Work-around: Write an explicit module-export.  You can also
use define-variable to force a "dynamic" variable.   Or
don't compile with --main (but then you don't get an
automatic main method).

(3) Currently, an integer literal has type gnu.math.IntNum,
i.e. a "bignum".  Adding an int and an integer literal is
usually done using IntNum arithmetic.  (The exception is
if the "expected type" is int, then the compiler knows it
can use int arithmetic and get the same result, thanks to
the properties of modular arithmetic.)

The plan is when an integer literal is in the 'int' range,
and is one of the operands to addition (or similar operation),
and the other operand has type int, then we cast the literal
to type int, and do the addition as int addition.  The
inferred type of the addition becomes int.  For example:

  (define (foo (x :: int))
     (let ((x10 (* x 10)))
         ... x10 ...))

Currently, the type inferred for x10 is integer (i.e. gnu.math.IntNum),
and the multiplication yields an IntNum result.  The plan
is that the type of x10 will be inferred to be int, and
the multiplication will be done by an inline imul instruction.

Motivation:  Performance.  Better type inference.  Fewer surprises:
I suspect most people would expect adding 1 to an int should
result in an int and be done using int addition.

Workaround, to get old behavior:  Cast either operand explictly
to integer.

(4) I'm also considering adding some warnings.  These would
be optional, but (probably) enabled by a new --warn-all flag.
One warning would be to warn when an operand to +, -, *
is untyped.  This is to make it easier to ensure you've put
in the needed type specifiers for the compiler to do a good job.

Another warning would be when both (all) operands to / are
exact integers, but not rationals.  This would be to protect
against unintended costly use of rationals and bignum-explosion;
most of the time it is better to use either inexact
floating-point (double) arithmetic, or the quotient or the
R6RS div functions.  The work-around would be to specify 'rational'
as the type of the operands or the expected result.

Comments?  Any of these seem like they would cause more pain
than gain?
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/