Former "smodel", now called hydroperx::sem, can be used in compiler infrastructures to designate symbol ("thingy") hierarchies with ease.

• The compiler uses an arena created implicitly by sem, and may invoke .clean() after long processes for forgetting one-reference-count garbages.
• A thingy is a simple wrapper over a complex Weak<__data__::Thingy>, where __data__::Thingy can further be something like __data__::Thingy { variant: __data__::ThingyVariant::Variable { variant: __data__::VariableVariant::__Nothing, x: 0.0 } }.
• Substructs are simply wrapping another thingy's struct.
• You don't do match yourself over "variants"; you use override fn, .is::<T>() or .to::<T>(), and may declare instance variables.
• There is super(); prefix in constructors.
• There is the super.m() expression.

Limitations:

• You can only define all thingy structs in one file, since the sem! macro got no way to split itself into different files for now. However I see the tendency that the classes tend to be vague if you implement some operations in separate Rust modules.
• When overriding a method, make sure to match the parameter names, due to macro hygiene issues.

Bugfixes:

• Fixed: The super constructor wasn't being invoked.

Unlisted advantages:

• When generating RustDoc, you'll see what a struct overrides (just ignore .is and .to, though).

Metavars

Implementing metavars in a compiler uses the technique of using a replacement field rather than mutating a thingy' instance itself, thus operations like equality must be mostly structural rather than referential.

1 post - 1 participant

Read full topic