Re: writing to parameter / type-switch

[Per Bothner <per at bothner dot com>]

On 11/29/2014 07:09 AM, Seth Alves wrote:
> I'm trying to run some code that does roughly this:
>
> (define (foo . opt)
>    (set! opt (if (null? opt) #f (car opt)))
>    opt)
>
> (display (foo 1))
> (newline)
>
> ./kawa-type-switch.scm:7:13: warning - type java.lang.Boolean is incompatible with required type list
> ./kawa-type-switch.scm:7:3: warning - cannot convert literal (of type java.lang.Boolean) to Type list
> Value '1' for variable 'opt' has wrong type (integer) (gnu.math.IntNum cannot be cast to gnu.lists.LList)
>      at kawa$Mntype$Mnswitch.foo$V(kawa-type-switch.scm:7)
>      at kawa$Mntype$Mnswitch.applyN(kawa-type-switch.scm:6)
> ...
>
> I can work around it, but is there a way to make kawa happy with this?

The reason is that Kawa automatically sets the type of a dotted parameter to 'list'.
Conceptually the fix is to implicit treat:
  (define (foo . opt) ...)
as:
  (define (foo . incoming-opt::list)

     (let ((opt incoming-opt)) ...))
We're not going to make this change until I make make sure no
extra code is generated in the normal case where the parameter isn't assigned to.
That isn't in principle difficult, but it means either awkwardly adding a
Scheme dependency in the non-Scheme-specific code - or Kawa needs to be
smart enough to combine variables when variable2 is initialized to variable1
and neither is further modified.

Shortly I will be working on changing how parameter are processed, partly to
support ML-style pattern matching.  It's not a priority right now.
If you want to enter a bug in the Kawa BugZilla that will make it easier
to not forget it ...

I'm not considering this a high-priority bug because of the easy work-around and
because frankly I consider the example pretty horrible style ...
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/