RFR: 8376223: Add modeling interfaces for algebraic structures: groups, rings, and fields

[Joe Darcy]

On Sat, 24 Jan 2026 05:14:16 GMT, Vladimir Kozelkov <duke at openjdk.org> 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