Example Showing Difference Between 'record' and 'table'

[JLPLabs]

Folks new to Pallene may find this example useful. It helped me get clear on the use of the two concepts 'record' and 'table'.

It has two modules, both of which define 'Point'. One defines it as a record and the other defines it as a table.

• Point1_module.pln: uses record
• Point2_module.pln: uses table

There is a main Lua file that demonstrates the differences in making calls into these modules.

• Point_main.lua: calls both modules

Point1_module.pln

-- Point demo, module #1 -- "record" example
--
--   * By design, Pallene does not allow record types to be used as parameters
--     or return values in the module API.
--   * Since this module does not define any tables we cannot use
--     tables that have named fields (though we can send arrays) as parameters
--     or return values, either.
--   * We can use the other primitive or composite types as parameters or
--     return values.
--   * Access to this module follows standard rules: function calls only,
--     there is no concept of a module data field.


local m: module = {}


record Point
    x: float
    y: float
end
local p: Point = {x = 10.0, y = 15.0}    -- default values

-- Module API cannot use 'record' (by rule) or 'table' (since we didn't define any)
function m.set(x: float, y: float)
    p.x = x
    p.y = y
end

function m.calc(msg: string, xs: {integer}, fn: integer -> string): (string, integer)
    local res = "calc got this message: " .. msg .. "\n"
    res = res .. "calc also got an array of integers (see size return val) \n"
    res = res .. "calc did 'fn(10)' and got: " .. fn(10) .. "\n"
    p.x = p.x * 10.0
    p.y = p.y * 10.0
    return res, #xs
end

function m.get(): (float, float)
    return p.x, p.y
end


return m

Point2_module.pln

-- Point demo, module #2 -- "table" example
--
--   * Since this module defines a table we can use tables
--     that have the same named fields, as parameters or return values.
--     In this example we show both.
--   * Access to this module follows standard rules: function calls only,
--     there is no concept of a module data field.


local m: module = {}


typealias Point = {x: float, y: float}
local p: Point = {x = 10.0, y = 15.0}    -- default values

-- Module API can use 'Point' tables in arguments and return types
function m.set(pt: Point)
    p.x = pt.x
    p.y = pt.y
end

function m.calc()
    p.x = p.x * 10.0
    p.y = p.y * 10.0
end

function m.get(): Point
    return p
end


return m

Point_main.lua

-- demonstrate differences in modules that use "record" and "table".

local M1 = require "Point1_module"    -- uses record
local M2 = require "Point2_module"    -- uses table

local function plus10(x) return tostring(x+10) end

-- M1 can't pass point table, as M1 has no point table defined, only a record,
-- and records can't be passed across the API, by design.
M1.set(42.0, 11.0)
-- We show sending various other types across the module API...
local res, size = M1.calc("hello moon", {42, 41, 40, 39}, plus10)
print("calc result: ", res)
print("calc size: ", size)
print("value: ", M1.get())


-- M2 access allows tables that match definition in module
local pt = {x = 42.0, y = 11.0}
M2.set(pt)
M2.calc()
pt = M2.get()
print("value: ", pt.x, pt.y)

running it...

calc result: 	calc got this message: hello moon
calc also got an array of integers (see size return val) 
calc did 'fn(10)' and got: 20

calc size: 	4
value: 	420.0	110.0
value: 	420.0	110.0

[hugomg]

In theory the record version should also allow non-primitive API parameters. Can you give an example of something that did not work? Maybe it's something that the current documentation isn't explaning very well...

[JLPLabs]

You are correct. I certainly need fix my wording. (I have started to edit the initial entry, but it is not done yet)
A quick check was done (as shown below) -- with no complaints from the compiler, and (after updating Point_main.lua) it worked as expected.

in Point1_module.pln:

function m.calc(msg: string, xs: {integer}, fn: integer -> string): (string, integer)
    local res = "calc got this message: " .. msg .. "\n"
    res = res .. "calc also got an array of integers (see size return val) \n"
    res = res .. "calc did 'fn(10)' and got: " .. fn(10) .. "\n"
    p.x = p.x * 10.0
    p.y = p.y * 10.0
    return res, #xs
end

Sometimes being particularly careful with words is useful (other times not so much..). I think this is a time where it would be useful.

For what it is worth
I started some notes regarding categories for the types in Pallene... I used a word ("composite") that doesn't appear in the documentation. Maybe it isn't a good fit here...

Primitive

• nil
• boolean
• integer
• float
• string (not included in the documentation as a primitive, but it seems more primitive than composite)

Composite

• array
• function
• table
• record

Other (not sure how to handle these)

• loop (this is called out in the documentation, in the types section; not sure how to think about it, really)
• any (this is better classified as a primitive??)

[hugomg]

Inside the compiler we call those "primitive types" and "garbage collected types" ("gc types"). However, I'm not sure if this is a distinction we need to bring attention in the documentation... Pallene doesn't treat primitive types differently than gc types.

loop (this is called out in the documentation, in the types section; not sure how to think about it, really)

Are you referring to recursive types? Those aren't implemented yet, but we want to add them in the near future.

any (this is better classified as a primitive??)

I think the more common convention for gradually typed languages is to put the "any" on a separate category by itself. But I'm not sure if there's a common name for it. Perhaps because there is less of a desire to name the category, because there is only one item inside it.

[JLPLabs]

I think you are correct that the distinction does need to be made in the documentation.

Maybe a simplified "table versus record" example should be put into examples section? That would have helped me quickly see how they are used differently.

[hugomg]

Sure, I think that discussion about when to use a record or a table certainly deserves to be somewhere in the manual and/or examples.

I'm only trying to figure out what's the most important part of the example :)

[hugomg]

I would like to keep using "primitive" with the meaning we use inside the compiler (for "not garbage collected types"). It also happens to be the same meaning from Java.

Maybe we could have a different name for what you're calling primitive. What about "basic types"? String would be a basic type (its type constructor has no type arguments) but it would not be a primitive type (it is garbage collected, and stored on the heap).

[JLPLabs]

I think that is a good idea.