This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: Kawa proposed typing changes
* Per Bothner [2009-09-26 18:34+0200] writes:
[...]
> One option is to follow R6RS: Disallow all set!s to
> any exported binding, even set! internal to the module.
> But that might break more code than desired. Another
> options is to prohibit module-external set! in the
> post-macro-expansion code. That should be easy to
> implement, and good enough. At some point we might
> consider deprecating or prohibiting this extension to R6RS.
Yep, checking it in the expanded code sounds good. Should also be
possible to give sensible error messages at that point.
[...]
> I think you misunderstand the plan. The literal 0 by-itself would
> still have type integer (bignum). I'm talking about when adding a
> literal integer with an expression that has already been inferred to
> 32-bit int.
>
> I.e. the type-inferencing rules are currently:
>
> (+ integer integer) --> integer
> (+ int integer) --> integer
> (+ integer int) --> integer
> (+ int int) --> int
>
> The change would be to add two special cases:
>
> (+ int integer-literal) --> int
> (+ integer-literal int) --> int
I see. I misunderstand this and yes, sounds like a useful idea.
A minor question is if
(+ int (+ integer-literal integer-literal))
has a different type than
(+ (+ int integer-literal) integer-literal)
>> or string conversions are needed.
>
> What "string conversions" were you thinking about?
Code like this:
(define (foo (s java.lang.String)) s)
(define (bar (s String)) (foo s))
(define (baz (s gnu.lists.FString)) (bar s))
(let ((x (string #\a)))
(list (instance? x java.lang.String)
(instance? (baz x) java.lang.String)))
=> (#f #t)
Apparently x gets converted to java.lang.String somewhere along the way.
>> Warnings about
>> improper tail calls would also be nice.
>
> I'm concerned about too many false positives.
> Any ides for avoiding that?
If there is a compiler switch like [no-]warn-tail-calls it could be used
as argument to with-compile-options on selected regions. Or the
compiler switch could also have arguments to name [un]interesting
functions like
(with-compile-options warn-tail-calls: (foo) no-warn-tail-calls: (bar)
(if x
(foo) ; warn
(bar) ; ignore
))
BTW, it would be useful if Kawa had a disassemble function which takes
procedures as argument. That would be much more convenient than
compiling to a class file and calling javap on it.
Helmut