Re: Kawa proposed typing changes

[Helmut Eller <eller dot helmut at gmail dot com>]

* Per Bothner [2009-09-25 21:52+0200] writes:

> (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".

How does this interact with macros?  A macro defined in module A may
expand to a set! expression when used in module B.  This would no longer
work, right?  Can R6RS macros expand to non-exported bindings?

> (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.

This sounds rather incompatible with standard Scheme.  E.g.
(do ((i 0 (+ i 1)))
    ((< i 0)))
usually loops (until memory is exhausted) but with modular arithmetic
the loop terminates after wrapping around.

It would be nice if there where a (rnrs) module where + overflows to
bignums and a (kawa) module where modular arithmetic is the default.

> (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.

Efficiency notes would be very useful.  I also would like a note when
integer boxing or string conversions are needed.  Warnings about
improper tail calls would also be nice.

> Comments?  Any of these seem like they would cause more pain
> than gain?

The changes seem to be for the better.  I hope, though, that Kawa
doesn't get locked down too much so that it's still useful for
interactive development.

Helmut