Upvalues and static typing

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Upvalues and static typing

Dibyendu Majumdar
Hi,

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')

Haven't thought yet how to fix this:
a) Probably easiest to disallow referencing typed values in up-values
b) Alternatively up-values need to be typed ... not sure if that is
possible to enforce at compile time

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Upvalues and static typing

Andrew Starks


On Friday, April 10, 2015, Dibyendu Majumdar <[hidden email]> wrote:
Hi,

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')

Haven't thought yet how to fix this:
a) Probably easiest to disallow referencing typed values in up-values
b) Alternatively up-values need to be typed ... not sure if that is
possible to enforce at compile time

Regards
Dibyendu


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. 

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?

-Andrew

 
Reply | Threaded
Open this post in threaded view
|

Re: Upvalues and static typing

Dibyendu Majumdar
On 11 April 2015 at 08:34, Andrew Starks <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Upvalues and static typing

Dibyendu Majumdar
In reply to this post by Dibyendu Majumdar
On 11 April 2015 at 03:45, Dibyendu Majumdar <[hidden email]> 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')
>

The fix I am implementing introduces new opcodes such as SETUPVALI -
this is like SETUPVAL but converts the value to integer. However, a
particular test in closure.lua fails after this fix:

a = {}
for i=1,10 do
  a[i] = {set = function(x) i=x end, get = function () return i end}
  if i == 3 then break end
end
a[2].set('a')

In Ravi the loop variable i is tagged as of type integer (based on
parsing results) - so in this case assigning 'a' is not allowed as it
fails the conversion to integer. So this code generates an error.

Based on earlier post by Roberto - assume this is okay as assigning
values to loop variables is undefined behaviour.

http://lua-users.org/lists/lua-l/2015-03/msg00024.html

Regards
Dibyendu