On Sat, 24 Jan 2026 05:14:16 GMT, Vladimir Kozelkov <[email protected]> wrote:
>> First cut at adding modeling interfaces for the algebraic structures of >> rings, groups, and fields. > > I apologize for writing this here, but I'm concerned about why operators are > so narrowly grouped together. And why aren't the operand and return types > separated? These are quite restrictive. > > Using this type of operator, it's impossible to emulate, for example, matrix > and vector multiplication. Because the operands are different types. And the > language already has an example of similar constructs—the string addition > operator, which takes a string and something else to produce a string again. > I'd like the operator mechanism to be able to fully model the current > behavior of the language. So that instead of a rigid construct within the > compiler, the string addition operator could be modeled in the same way as > other operators. > @vova7878 Such discussions are premature. This PR is an experiment, nothing > more. We will take what we've learned from the various experiments and bring > them to the actual design discussions, when they happen. But for now, this is > just a place to stash an experiment. A bit more context, the situation with homogeneous typing -- alpha op alpha -> alpha -- was acknowledged and discussed in my 2025 JVMS talk on numerics (slides: https://github.com/jddarcy/SpeakingArchive/blob/master/JVMLS-2025-Numerics.pdf, video: https://youtu.be/xCdJb_zI5us). Quoting starting from slide 51: > Type classes and operator overloading > • Assume homogenous typing > α op α → α > is sufficient for operator overloading > • In other words, do not attempt (initially) to support mixed-type operators > • Some of the effect of mixed-type operators can be implemented via > conversions > • Assume only identity-less classes will be eligible for operator overloading > • Assume not all operators will be eligible for overloading. Some compound > operators may at most be overloaded indirectly via a compiler-generated > composite of a non-compound overload; e.g. += built out of +. > > Implications of assumptions > • Homogeneity does not necessarily provide ideal support for > • Complex arithmetic > (would benefit from direct double op complex, imaginary op complex and > imaginary * imaginary → double, > imaginary + double → complex, etc. > Possible, if costly, to implement these more precise checks inside a complex > type.) > • Matrices > Matrices can be multiplied together and multiplied by a scalar of the type of > the > entities of the matrix. If only Matrix * Matrix multiply is supported, 1x1 > matrix and a > scalar are distinct concepts, but systems can work out conversions/coercions > between > the two. It would be technically possible to encode the dimension of matrices/vectors into a type system, but I would expect any dimension compatibility to be implemented via runtime checks. (As a reference point, way back when Pascal included the size of an array as part of its type and this complicated many useful tasks like, say, writing library routines that accepted arrays of any size.) ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1957#issuecomment-3795359818
