Re: No C<pow> op with PMC arguments? (Modified by Jeff Clites)
Jeff Clites
On Nov 5, 2004, at 10:39 AM, Brent 'Dax' Royal-Gordon wrote:
> Jeff Clites <jcl...@mac.com> 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