Passing lua tables to a pallene script?

[srijan-paul]

Hi,
What is the easiest way to pass a lua table to Pallene script at the moment?
For example, If I want to pass an existing Lua implementation of 2D vectors, I'd like to be able to pass it to Pallene scripts to perform operations on it.

local function vec2_mag(p: table): float
	return math.sqrt(p.x as integer * p.x as integer, p.y as integer * p.y as integer)
end

Right now, the closest I can get is to pass the members explicitly for simple tables.

export function vec2_mag(x: float, b: float): float
   return math.sqrt(x * x, y * y)
end

But for tables with many members, this gets a bit hairy.
Don't know if this can somehow be done at the moment, but the manual doesn't seem to mention it.

[hugomg]

You can use a table type.

local function vec2_mag(p: {x: float, y: float}): float
	return math.sqrt(p.x * p.x, p.y * p.y)
end

You can also use a typealias to give a name to the type

typealias Point = {x: float, y: float}
local function vec2_mag(p: Point): float

[srijan-paul]

Ah, that is true.
If Pallene had sum types, the return type of the subscript operator on a { K => V } table could be V | nil.

Without them, I guess one idea could be to use something similar to C++'s std::unordered_map like API?

std::unordered_map<int, bool> ib_hmap;
auto entry = ib_hmap.get(12);

if (entry != ib_hmap.end()) {
  bool val = entry->second;
  // use val
}

The map[key] query, instead of returning the value that key is mapped to, would return an entry (in C++, its an std::pair<K, V>). The user can then check if the entry is valid or not before actually using it. If the entry is valid then they extract the value. Accessng the value field of an invalid entry can then result in an error perhaps?

local entry: Entry = map[10]
if entry.is_valid then
  local x: integer = entry.value
  -- use x
end

This way when the user is certain that an entry exists, it's ok to index the .value field without a check.

Table* map = // ...
TValue key = {0, {0}};
setnvalue(key, 10);
TValue v = luaH_get(map, key);

Entry en = { ttisnil(v), &v };

if (en.is_valid) {
  PALLENE_CHECK_ENTRY_TT(en.value, LUA_TNUMBER); // error on tag mismatch
  int x = ivalue(en.value);
  // use x
}

Although I assume this isn't ideal either since we usually expect map[key] to be of type Value and not some wrapper around value. Furthermore, this would require the lua backend to generate different code for Pallene maps.

local x: V = map[key] would have to transpile to local x = { is_valid = map[key] ~= nil, value = map[key]}.
Simply removing the type annotations would no longer work. This is unlikely to be preferable.

Typescript handles Javascript's Map s .get method using sum types (V | undefined for Map<K, V>). Even though Pallene has more constraints because of compiling to C, maybe using a similar approach when/if sum types are implemented can simplify maps a bit?

The simplest approach I can imagine until then is for map[key] to return a value of type any and then compare that with nil to confirm that the value does in-fact exist in the map, before type casting it to V ?

I'm curious if there are other ways to tackle this.

[hugomg]

Simply removing the type annotations would no longer work. This is unlikely to be preferable.

You hit the nail on the head. As a rule of thumb we try to ensure that erasing types to produce a Lua program should not change the behavior of the problem.

The simplest approach I can imagine until then is for map[key] to return a value of type any and then compare that with nil to confirm that the value does in-fact exist in the map, before type casting it to V ?

Exactly.

local x_any = mymap[key]
if x_any ~= nil  then
    local x = x_any as T
else
    -- Not found
end

A more complex approach would be to do something similar to Typescript's type narrowing. That is, a test like if x ~= nil or if type(x) == "number" would cause the x variable to have a more specific type inside the then branch. But we'd have to figure out the details. It would have to balance being flexible but not too much complicated to reason about or implement.

Another possible inspiration could be is operator in Teal.

[srijan-paul]

Type narrowing sounds like a good idea. Without sum types, it probably won't be that difficult to implement for == and !=.

The is operator is pretty neat as well. Though I'm not sure how it would translate over to the runtime when the right operand is a pallene record type. Teal doesn't allow anything other than lua types for is's RHS.

[hugomg]

Though I'm not sure how it would translate over to the runtime when the right operand is a pallene record type.

Pallene already has to know how to check types at runtime; we do that when Lua calls a Pallene function, or when we read values from a Lua table.

For Pallene record types, we use the metatable to check the type. For function types we just check that the value is a function and then we check the result types after every CallDyn.

Without sum types, it probably won't be that difficult to implement for == and !=.

I suspect that the trickiest part would be to work out the exact type system rules and also decide what kinds of conditionals can be used for type narrowing.

Implementation wise, the IR part of the backend assumes that local variables have function scope and that the type of a local variable doesn't change inside the function. If we choose to implement type narrowing, one thing we could do is to have it generate IR that's similar to the more verbose version with the x and x_any.

[srijan-paul]

I suspect that the trickiest part would be to work out the exact type system rules and also decide what kinds of conditionals can be used for type narrowing.

True, I think it might help to have some kind of document specifying the exact rules (perhaps some place like doc.md?).
We could use the page from the typescript handbook you linked earlier as a loose reference perhaps. Though there are definitely edge cases that are easier to reason about in TS.

record Foo
  x: any
end

local my_foo: Foo = { x: 1 }
local my_foo.x = map[key]
if my_foo.x ~= nil then
 -- does my_foo.x get narrowed here?
end

handling narrowing in to_ir by generating appropriate IR sounds like a great idea.
Assuming this type narrowing only applies to Maps, the IR might generator have to 'see' which lvalues of type any are a result of a lookup so that they can be narrowed.