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: 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


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