Generators and relationships in the bootstrap

1 view
Skip to first unread message

Bill Cox

unread,
Apr 17, 2023, 4:31:07 PM4/17/23
to Rune language discussion
The implementation of generators in the C Rune compiler is a hack, with just enough implemented to get the main relation generators to run.  Basically, the C Rune compiler interprets the HIR (High Level IR) to generate code, but only a tiny subset of the language is supported by the interpreter.

In the bootstrap, I think we should work more like Rust macros, and compile the generators and link them into the compiler.  Some could be statically linked, and users could provide .so files that load at runtime.

Relation statements are just syntactic sugar for calling the generators.  Consider:

    relation DoublyLinked Node:"From" Edge:"Out" cascade

This just turns into:

     generate DoublyLinked(Node, Edge, "From", "Out", true)

which does the same thing.  Additional parameters passed to the generator are specified in parentheses at the end, such as

    relation Hashed Symtab Symbin cascade ("hash")  // The extra parameter specifies the hash map key data member.

I think we should add syntax to pass expressions to the generators. Today, the interpreter creates dbValue instances from parameters, and attaches those to the generator's input parameter variables so the body of the generator can be interpreted.  For example:

    relation Hashed Dict<keyType, valueType> Entry<keyType, valueType> cascade

Instead of passing references to tclasses for Dict and Entry, we'd pass dbValue objects holding deExpression references.  The identifier expansion would ignore the type spec and just use the tclass name.  When replacing identifiers in statements like:

    self.$labelB$B_Table = arrayof(B)

We'd get:

    self.entryTable = arrayof(Entry<keyType, valueType>)

instead of the non-fully-specified output we get today:

    self.entryTable = arrayof(Entry)

Because we don't know the fully qualified type for Entry here, today the Rune compiler sometimes needs type hints to allow it to figure this out, such as:

    if false {
        self.entryTable[0] = entry
    }

Bill
Reply all
Reply to author
Forward
0 new messages