On the argument of “element-wise usefulness” alone you’re right, but that’s only a small part of the system:
I see a fundamental difference with vector in that they intend to map to “register”, they are “packed” and have a “defined” memory layout, which isn’t the case for tensors.
Vectors are meant to be mixed with scalars and correspond to a somehow well identified layer of the progressive lowering.
Sure, but this does not seem to me to be an argument for mixing tensor inside the standard dialect instead of separating the tensor domain. Quite the opposite actually: if I design a system that works on the tensor domain, I’d like to be able to use ops that are restricted to the tensor domain that I can interact more safely with.
In terms of getting to well identified and separate components that can be isolated, I really believe that getting a smaller scope for the standard dialect is getting us in a better space.
Getting a dedicated dialect would allow both this dialect and standard to be more strict, which leads to a more robust system ultimately: the narrower the API the easiest it is for user to not be surprised and implement the contract correctly.
This is also consistent with the general IR design: for similar reason that std.addi if split from std.addf, when I match an operation I need to handle it consistently. We don’t want passes to crash when they are fed with valid IR, and if the standard dialect operations accept tensors then we need to defend against it everywhere.