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: GSOC | Extending Common Lisp support


* Charles Turner [2012-04-26 22:18] writes:

> Thanks for the explanation Jamison. I haven't incorporated your latest
> suggestions, but I attach my most recent work on the scoping, most of
> the scoping scenarios I could think of have seem to work.
>
> One thing I noticed today which didn't make much sense to me was the following:
>
> (define (test)
>   (let ((x :: integer 10.5))
>     (* x x)))
> /dev/stdin:2:23: warning - type DFloNum is incompatible with required
> type integer
> /dev/stdin:3:5: warning - cannot convert literal (of type
> gnu.math.DFloNum) to Type integer
>
> So far, as expected. But when you type (test), you get:
>
> Value '110.25' has wrong type (DFloNum) (expected: integer)
>
> Note that is the result of (* x x), not the initial static type. What
> good is that if you're wanting static type safety?

>From a philosophical point of view, type declarations in Lisp don't
change the semantics, i.e. a program with declarations should produce
the same results as the program without (though it could be more
efficient or give extra warnings).  It's also in line with tradition to
emit a warning at compile time but still generate code that will raise
an runtime error.  IMO Kawa acts quite gracefully here.

A different story is this example:

(define (test)
  (let ((x :: int 10.5))
    (* x x)))

Kawa returns 110 which seems quite wrong.


> I note that the
> warnings at least point to the cause in the case of a disaster, but is
> this something that could be more strongly typed?

Turning all warnings into errors would help ;-)

Helmut


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