[missed cc-ing the list when I sent this originally]
On Nov 5, 2004, at 10:39 AM, Brent 'Dax' Royal-Gordon wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:There are a
myriad of interesting mathematical types and operations, but they don't
need dedicated ops to support them.
But we're not talking about adding pow_bignum, pow_complex and pow_matrix. We're talking about adding pow--a fundamental operation by most standards--and a bignum, complex number, or matrix can Do The Right Thing when pow is called on it.
What's bugging me is that PMCs are not meant to be specifically mathematical types--of the 72 in classes/*.pmc, only a few are. "pow" isn't a fundamental operation, by my thinking, on PMC types--it makes no sense for most of them. (Similarly for other mathematical operations.) Modeling these as method calls, rather than ops, seems to be a better fit conceptually. And if you look across languages, it makes even more sense (specifically in the case of mathematical infix operators): Java doesn't have operator overloading, and would use method calls anyway; Ruby explicitly treats infix operators as an alternative syntax for method calls; and Python semantically behaves this way as well.
(And even the seemingly "obvious" cases aren't: There are at least three different operations on vectors which could be called "multiplication". I don't think the "mul" op should be used for any of them.)
I would assume "mul" on a matrix would perform the same matrix multiplication the public school system tortured me with in Algebra 2 and Precalculus.
But I said vectors, not matrices. For vectors, you have dot product (inner product), cross product (outer product), and component-wise product (not often used in math, but useful in programming). Three different things which have equal claim on "mul". There's not a one-to-one correspondence between fundamental operations on ints/floats and other mathematical types.
What I *can* see a case for is removing *all* binary ops from their current special "pseudo-vtable" status; instead, create special names for them that won't conflict with anything, and turn them into normal methods (or normal multimethods, as the case may be).
Yes, that's my thought. I think that we should only have PMC ops which make sense for most PMC types (or which are needed for basic interpreter functionality, like "invoke")--it would make for a fairly short list. I don't think that we should have an op for PMCs just because we have a corresponding op for ints and floats. And no matter what, in terms of methods naming we'll need some mechanism for exposing a given method with different names for different languages--what shows up as "__mul__" in Python should show up as "multiply" in Java and "*" in Ruby. That's something which hasn't been addressed/discussed yet.
But that can't happen until we have N-ary multimethod support which scales well
enough that we don't have to worry about the multimethod table
becoming too big.
Though in the case of Python, these don't act as multimethods--they dispatch on the left operand only.
JEff
