On Tue, 2004-04-20 at 16:30, Dan Sugalski wrote:
> Because they can be overridden separately from the regular version of
> the operation.
Of course.
Quoting A3 (note, syntax has changed, but as far as I know, the content has not):
@a ^* @b
is equivalent to this:
parallel { $^a * $^b } @a, @b
So, while they can be overridden separately in the client language, I
don't think that requires any support from Parrot (after all, Python
objects won't override their infix:>>+<<, but they might override their
infix:+, and that should carry over to Perl 6 when hyper-adding Python
ints).
> Because if they're separate, people can do Really Evil Things with
> them. (Like, say, custom matrix manipulation code with assembly
> routines that use MMX, SSE, or Altivec functionality)
>
> Because the things being operated on may give the compilers
> insufficient information to generate at compile time the proper array
> iteration code.
Your talk began with the woes of dynamic languages. You explained to us
in great detail how polymorphism and the lack of any sort of static data
lead to the inability to optimize in this way.
What changed?
Specifically, if I have:
@a >>+<< @b
Why is it that I can apply MMX instructions, even if I think I know the
types of everything in @a and @b (e.g. because of a declaration). What
if element 10 of @a is REALLY a URI fetch object that got put in there
by some library? Worse, will the MMX instructions obey the semantics of
a host of language-specific PMCs all crammed into one array?
You seem to be eager to do this, and I won't try to stop you, but I
guess I am curious why you want to do this so badly....
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
