Defining methods #T, X#Y, and X.Y

[mahrud]

Currently it's not possible to assign methods for these operators:

i1 : X = Y = T = new Type;

i2 : #T := identity
stdio:2:4:(3): error: can't assign a method for this unary operator

i3 : X#Y := identity
stdio:3:5:(3): error: can't assign a method for this binary operator

i4 : X.Y := identity
stdio:4:5:(3): error: can't assign a method for this binary operator

However, there's definitely code that hints at the possibility of doing this: https://github.com/Macaulay2/M2/blob/1fd238210e9a37ddaec3b700ccd22f06ff5f28f5/M2/Macaulay2/d/convertr.d#L330-L354

I removed this chunk in 3fe2b0d8395d1290f62e8887ebbeb72a8e7c338a and nothing seems to have broken. If we add SharpS and DotS to opsWithBinaryMethod and opsWithUnaryMethod in binding.d then the methods can be defined without an error, but then they're not usable:

i5 : ZZ#ZZ := identity

o5 = identity

o5 : CompiledFunction

i6 : 2#3
stdio:6:1:(3): error: expected a list, sequence, string, net, hash table, database, or dictionary

So what is the point? Was this an incomplete feature, or was this intentionally disabled because defining methods for these operations introduced ambiguities? What do we want?

[d-torrance]

I think adding a final binarymethod to subvalue in hashtables.dd (which would probably require moving around some stuff, since binarymethod is defined in evaluate.d, which depends on hashtables.dd) might make it so that we could overload # as binary operator for classes that aren't lists, hash tables, etc, similar to how the arithmetic operators work.

I would love to overload . for the Python package to follow Python syntax more closely. Right now, it uses @@ instead since the precedence is halfway similar. The big problem with ., though, is that we check that the right hand side is a global symbol right away in binding.d.

[mahrud]

This doesn't seem to work. See https://github.com/mahrud/M2/commit/51398477774495db5ea86dbcd217aa4dec4cbe83.