This permits external consumers of MLIR to easily parse attributes/types,
since we guarantee to print the generic form of the attribute/type
as !dialect<"name<args>"> / #dialect<"name<args>">.
Details
- Reviewers
rriddle mehdi_amini ftynse
Diff Detail
Event Timeline
You can already easily parse attributes/types (they have a limited syntax, see what the MLIR parser does for this), and we are actively trying to remove the string form.
@rriddle as an external consumer of MLIR, it is quite annoying to have to parse both foo<"..."> as well as foo.bar<balanced-parens>.
It would be much more pleasant to have one or the other, *especially* since it seems like foo<"..."> isn't going anywhere anytime soon, since the syntax opaque syntax of a raw string is more expressive than the pretty syntax. [For example, as you know, the opaque syntax allows the string to have imbalanced parentheses such as foo<">">.]
I understand the frustration, but making things easier for external users to parse is not a motivating driver for developments/stability/etc. of the MLIR parser. This is especially true when they desires are counter to the direction that we want to drive the project.
@rriddle maybe you can expand on this? In particular since you mentioned
we are actively trying to remove the string form.