I’m designing a type system for a messaging system. Since it can (theoretically) transport any data, I would like it to be an open type system. Given that the actual implementation(s) will need some information about all the underlying types (i.e. how large it is), I’m hoping that any type will be able to support it by adding some additional information in some sort of standard fashion – I haven’t thought about this too much since for now it’s acceptable to have a closed type system. I just don’t want to do anything to preclude an open type system in the future.
More importantly, I think carrying around a separate context precludes (or makes significantly more complex) my generic tablegen-based type generation’s printer auto-generation support if I want it to support recursive type systems.
Couldn’t we simply add the context to DialectAsmPrinter? I’m not certain, but isn’t the same instance passed through the printType method regardless of the dialect? A stack of Type should be general enough, and printType could manage it.
Assuming this sort of thing can be done, my one other minor concern is bloat in type output due to redundancy.
I’m not familiar with the structure of any MLIR code, but isn’t this just a simple question of requiring the various type printers to request another type be printed after the one currently being printed? You’d probably need some additional accounting to make sure it hasn’t been printed within that scope. This would avoid having to keep some context with the printer.
I don’t think this requires region-scoped aliases or forward alias references (as you’ve discussed) since the types themselves would still be required to resolve references themselves. This would merely control the type printing.
I’m not pushing for this approach, just trying to understand the issues with it. Feel free to point me to some documentation/code on the subject – I may just be missing some context.