Re: Upvalues and static typing

[Dibyendu Majumdar <mobile@...>]

On 11 April 2015 at 08:34, Andrew Starks <andrew.starks@trms.com> wrote:
>> While working on the core API the realization dawned that up-values
>> can subvert static typing of local variables :-(
>>
>> > function x() local i: integer; return function(j) i = j; end; end
>> > f=x()
>> > f(5)
>> > f('hello')
>>
> I don't understand. Is it a design problem or implementation issue? As a
> design question, it seems straightforward. The last line should error and
> that seems unambiguous to me.

It is a defect in that currently the type of up-values isn't known so
compiler cannot enforce.

>
> local i: integer --declaration.
> return function(j) --argument j is declared as a non-typed value.
>   i = j --at runtime, you'll need to check if j is an integer or not because
> i is a reference to a static type.
> ...
>
> Anything other than that would be confusing to me, r am I missing something?

Agree that this would be the ideal behaviour. Question is how to
implement this - which is something I need to figure out. I will
probably implement something similar to what I did for scenario such
as:

local i: integer = f()

Here I generate bytecode TOINT to convert the result of the function
call. (The compiler knows that i is meant to be an integer in this
case.)

> function x(); local i: integer = f(); end
> ravi.dumplua(x)

function <stdin:1,1> (4 instructions at 000000391BBDFBA0)
0 params, 2 slots, 1 upvalue, 1 local, 1 constant, 0 functions
        1       [1]     GETTABUP        0 0 -1  ; _ENV "f"
        2       [1]     CALL            0 1 2
        3       [1]     TOINT           0
        4       [1]     RETURN          0 1
constants (1) for 000000391BBDFBA0:
        1       "f"
locals (1) for 000000391BBDFBA0:
        0       i       4       5
upvalues (1) for 000000391BBDFBA0:
        0       _ENV    0       0