Skip to content

Well Specified Procedural Block

No due date 66% complete

Currently, proc blocks are mostly implemented on an ad-hoc basis with a lot of work left up to the Rust compiler to catch bugs.

We want to take advantage of Rust's procedural macros to enforce a consistent structure and generate metadata, then use WebAssembly custom sections to give external programs access to that metadata without needing to execute the …

Currently, proc blocks are mostly implemented on an ad-hoc basis with a lot of work left up to the Rust compiler to catch bugs.

We want to take advantage of Rust's procedural macros to enforce a consistent structure and generate metadata, then use WebAssembly custom sections to give external programs access to that metadata without needing to execute the unknown proc block. This is currently done using #[derive(ProcBlock)].

As it is, while we've been generating this metadata for a while, it isn't actually used by anything. That means the way a proc block is implemented and the way it is used can diverge, causing cryptic compilation errors because rune build blindly generates invalid code.

There are roughly 3 pieces of information external programs need to know about a proc block:

  • What is the proc block?
    • Name
    • Human-friendly description
  • Which arguments does it support?
    • Arguments have a name (e.g. width) and can be set to a string (see #237)
    • Human-friendly description of the argument
    • Is it possible for an invalid argument to trigger an error?
  • Which transformations does the proc-block support?
    • What are the input and output types?
    • Are there any dimension constraints? (e.g. this proc-block can only accept 1D inputs)

Later on, we may also include things a proc block requires from the runtime in order to run (e.g. extern "C" functions for hardware-accelerated operations).

See also #328.

Loading