IntAttr vs IntegerAttr

[Dinistro]

Currently, IntAttr is defined in builtin but there is also a IntegerAttr. I think we should either remove IntAttr or rename it to something else.
This caused quite some confusion, e.g., https://github.com/compiling-techniques/ChocoPyCompiler/pull/75/files

[math-fehr]

I would prefer not removing IntAttr, because its purpose is to encapsulate a python int.
However, we can indeed rename it to something else!

[Dinistro]

There is no rush for such a thing. I just wanted to write this down somewhere.

[K-W-Li]

At first sight I thought it was like Haskell's Int (bounded) and Integer (unbounded) but looks the other way round.

[K-W-Li]

Can we make the bounded integer inherit from unbounded integer? So we can access the value by ".data.value" instead of ".data.data.value"

[math-fehr]

Hey! A bit of explanation on the IntAttr versus IntegerAttr.
An IntAttr is an attribute that only contains an integer.
An IntegerAttr is an attribute that contains an IntAttr and an IntegerType. This is a way to have a typed integer.
The problem is that the naming is not that great. One proposition Michel had was to change IntegerAttr to ValueAttr, which makes more sense in my opinion! The only problem is that we would need to write some more code for the translation to MLIR.

[webmiche]

Or maybe TypedIntegerValue?

[PapyChacal]

Walking the issues for some reason; forgot this even was a problem as I got through it myself, but it would make sense to solve that still!
I would be in favor of keeping IntegerAttr as-is for MLIR consistency; IntAttr being the xDSL novelty, we could make this one more explicit? Like IntegerValueAttr or something in that direction?