Request for Adoption of Lua Metaprogramming Features in Typst

[LamprosPitsillos]

Description

Overview

Typst project currently utilizes typst for scripting
purposes. While typst serves its purpose adequately, I believe
incorporating metaprogramming features inspired by Lua could significantly
enhance the flexibility and extensibility of our scripting environment.

Proposal:

I propose the adoption of some of Lua's metaprogramming features within the
project's scripting language.
Lua's metaprogramming capabilities, such as
metatables and metamethods enable powerful customization and extension
of the language's behavior at runtime.
By integrating similar features into our scripting environment, we can empower users to dynamically modify and enhance script behavior to better suit their needs.

Requested Features:

Specific metaprogramming features from Lua that I believe would greatly benefit our project include:

• Metatables: Lua's metatables provide a mechanism for defining custom
  behaviors for tables, enabling users to implement operator overloading,
  custom indexing, and other advanced features within their scripts.

• Metamethods: Lua's metamethods allow users to define special methods
  that are invoked in response to specific operations (e.g., arithmetic
  operations, table access), providing a powerful tool for customizing
  script behavior and implementing domain-specific language constructs.

I purposely avoided recommending syntax as that is one of the most subjective and polarizing topics and not worth discussing in this stage.

I welcome feedback and discussion from the community on this proposal, as I understand this is a huge request.

Thank you for considering this request.

Use Case

Examples

For the examples lets create a Dictionary ( object ) Frac and Matrix:

#let Frac(numerator, denominator)= {
    ...
    (_type: "Frac", num: numerator, denom: denominator)
}

#let Matrix(values: (), dim: (rows: "n", cols: "m"), name: [M])= {
    ...
  (
    _type: "Matrix",
    values: values,
    dim: (rows: rows, cols: cols),
    name: name,
  )
}

#{
let foo = Frac(1,2);
let bar = Frac(1,3);
let baz = Frac(1,4);


// Desired abstraction
// assuming a metafuntion was provide (__add , __mul, __lt)
let cond = (foo < bar )
let x = ( foo * bar  ) + baz

// Current solution
let cond = Frac_lt(foo , bar )
let x = Frac_add(Frac_mul(foo,bar),baz)

---

// Desired abstraction
// If an object is required as a content,
// and has implemented the appropriate metafunction
// assuming a metafuntion was provided (__tocontent) the following could be enough
[ #x ]

// Current solution
let Frac_to_content(F) = { ... }
[#Frac_to_content(x)]

---

// Desired abstraction
// assuming somekind of `self` could be provided
// maybe : ` Frac.simplify(self) = {...}
// or    : ` Frac:simplify() = {...}
let m = Matrix(...)
let y = x.simplify()
let mT = m.transpose()

// Current solution
let y = Frac_simplify(x)
let mT = Matrix_transpose(m)


// Desired abstraction
// assuming a metafuntion was provided (__index) the following could be enough
// notice the custom type and the not normalised values for better human readability
// anything could be possible since this is a user function
let val = mT.at((1,3))
or
let val = mT.at((row:1,col:3))
or
let val = mT.at((row:1)) // returns the row
or
let val = mT.at((col:3)) // returns the col


// Current solution
let val = mT.values.at(0).at(2)

// The above where some minimal examples that on their own might seem a bit unnecessary
// but consider the following overcomplicated example.
let A = Matrix(...)
let B Matrix(...)

let C = ( ( A*3 ) + (B.inverse()) ) * I.transpose()

let C = Matrix_mul( Matrix_add( Matrix_scale(A,3)),(Matrix_inverse(B)) ),I)
}

[MDLC01]

I think some of the features you mentioned are covered in this blog post : https://laurmaedje.github.io/posts/types-and-context/.

[LamprosPitsillos]

I think some of the features you mentioned are covered in this blog post : https://laurmaedje.github.io/posts/types-and-context/.

Thank you , many of the things i tried to discuss are much better said in the blog post mentioned.

[laurmaedje]

As mentioned, support for custom types is planned.

This issue is pretty broad, so that it really feel actionable as a feature request to me. It's maybe better suited as a discussion.

For more individual things like operator overloading a feature request might make sense, but I think we shouldn't get ahead of ourselves and add support for custom types at all first.