S13: Deep operators

[Matthew Walton]

This is just to clarify something from S13.

If I declare, for example

multi sub *infix:«+» (EvilNumber $lhs, EvilNumber $rhs) { ... }

Then if I run

my EvilNumber $a;
my EvilNumber $b;

my EvilNumber $c = $a + $b;

I get my code, but

$a += $b;

Will attempt the default behaviour for +=, which is liable not to work.
However, if I alter my operator overload to be

multi sub *infix:«+» (EvilNumber $lhs, EvilNumber $rhs) is deep { ... }

I get *infix:«+=» defined as { $lhs = $lhs + $rhs; } for free. Is that
right?

Also, would things blow up if I specified the return types for operator
overloads, such as

multi sub *infix:«+» (EvilNumber $lhs, EvilNumber $rhs) returns
EvilNumber is deep { ... }

Would that work, would it behave strangely and what would it do to the
definition of infix:«+=» which would be based on it? Is it even
necessary? Does it give me anything? And can I overload based on return
types?

Thanks

Matthew

[Luke Palmer]

Matthew Walton writes:
> However, if I alter my operator overload to be
>
> multi sub *infix:«+» (EvilNumber $lhs, EvilNumber $rhs) is deep { ... }
>
> I get *infix:«+=» defined as { $lhs = $lhs + $rhs; } for free. Is that
> right?

Yep.

> Also, would things blow up if I specified the return types for operator
> overloads, such as
>
> multi sub *infix:«+» (EvilNumber $lhs, EvilNumber $rhs) returns
> EvilNumber is deep { ... }

In that case I don't see why it would blow up. If you said, say:

multi sub *infix:«*» (Vector $lhs, Vector $rhs)
returns Num is deep
{ ... }

Then you might get into trouble if you did

$u += $v

> Would that work, would it behave strangely and what would it do to the
> definition of infix:«+=» which would be based on it? Is it even
> necessary? Does it give me anything? And can I overload based on return
> types?

I can't be sure, but I don't think that we're doing MMD on return types.
The most compelling reason for that is because you can get yourself into
paradoxes that way.

Luke

[Matthew Walton]

Luke Palmer wrote:
>>Also, would things blow up if I specified the return types for operator
>>overloads, such as
>>
>>multi sub *infix:«+» (EvilNumber $lhs, EvilNumber $rhs) returns
>>EvilNumber is deep { ... }
>
>
> In that case I don't see why it would blow up. If you said, say:
>
> multi sub *infix:«*» (Vector $lhs, Vector $rhs)
> returns Num is deep
> { ... }
>
> Then you might get into trouble if you did
>
> $u += $v

Or even
$u *= $v
:-)

Yes, I can see that would be a problem. Care obviously required with the
types of operator methods as in other languages.

>>Would that work, would it behave strangely and what would it do to the
>>definition of infix:«+=» which would be based on it? Is it even
>>necessary? Does it give me anything? And can I overload based on return
>>types?
>
>
> I can't be sure, but I don't think that we're doing MMD on return types.
> The most compelling reason for that is because you can get yourself into
> paradoxes that way.

I didn't think we would be, as it would be hideously difficult to pick
the right method to dispatch to, but I thought I'd check.

Thanks

Matthew

[Larry Wall]

On Mon, Nov 22, 2004 at 07:51:29PM +0000, Matthew Walton wrote:
: And can I overload based on return types?

In the case of an MMD tie, the default routine could use the return
type context to break the tie. That's about the limit of what's
practical, I suspect. Possibly we could give some declarative support
to such tiebreaking, but hey, it's like one switch statement max:

given want {
when GoodNum {...}
when EvilNum {...}
when MyNum {...}
when YourNum {...}
when Num {...}
when int {...}
when void {...}
}

On the other hand, in a language like Perl, it's easy to come up
with contexts that don't specify the type context as well as the user
might expect. Plus asking for your return context is not necessarily
going to be terribly efficient anyway if it has to chase up some stack
somewhere looking for the caller, so it's not a programming style we
particularly want to encourage anyway.

Larry

[Luke Palmer]

David Ross writes:
> How much of the overhead for method dispatch/return is or can be
> incurred at compile time? If call and return signatures are defined at
> compile time is it possible to eliminate switch code and/or jump
> tables as an optimumization?

We hope so, in the absence of a pragma telling us not to.

In fact, the direction the grammar engine is going seems to be a very
good one. Basically we do all the work we possibly can in "compiler"
modules, and then generate the code we end up running. This can be
done at every stage of the game for Perl 6.
>
> From what I have learned attributes (handlers) and
> BEGIN/CHECK/AUTOLOAD blocks are part of the answer. They provide for
> building and manipulating the symbol table. What I have been searching
> for is a way of triming the control flow graph.

Hmm... are you still asking about Perl 6? Because I can tell you about
that, since it doesn't exist and I can make up whatever :-). If you're
asking about Perl 5, then go to the "applied programming" department,
perl5-porters. :-)

In Perl 6, we can't trim the control flow graph after it's been built.
The graph determines what register numbers are used, etc., and it can't
be retroactively changed. But we can trim before we generate the code.
In fact, constant folding does that.

Perl 6 will have to be much more liberal than Perl 5 in optimizations.
Perl 6 has hooks *everywhere*, and checking for all of them all the time
would slow execution to a crawl. Fortunately, a lot of the hooks are
lexical, so we can tell when we have them and when we don't.

Better yet, module implementors can use these hooks because of macros
and compile-time evaluation (as you mention, BEGIN blocks are very
important). So a module can tell the compiler that this hook is really
here, even though it doesn't look like it, and the correct code can be
generated.

> Sorry if this is off topic or dated. I have recently return to
> developing in PERL struggling to catch up. The conceptual and concrete
> progress is awesome.

Thanks. Sorry if my answer didn't answer your question. I get the
feeling I took your words and made my own question out of them, and
then answered it...

Luke

[Juerd]

David Ross skribis 2004-11-24 12:00 (-0500):
> I have been studying PERL 5 core and modules to identify options and
> issues for meta-architectures and automated code generation. PERL 6
> documents and discussion provide insight essential to effectively using
> PERL 5 and preparing for PERL 6.

If PERL 5 is open source, could you send me a copy? I know about Perl,
and use perl every day, but I think I read somewhere that PERL is better
for CGI programming.

:)

See also perlfaq1.

Regards,

Juerd

[Michele Dondi]

<OT>

On Wed, 24 Nov 2004, David Ross wrote:

> I have been studying PERL 5 core and modules to identify options and
> issues for meta-architectures and automated code generation. PERL 6
> documents and discussion provide insight essential to effectively using
> PERL 5 and preparing for PERL 6.

[snip]

> developing in PERL struggling to catch up. The conceptual and concrete

Funny to notice how you could study PERL{5,6} so much still failing to
realize that there's not such a thing as "PERL". See

perldoc -q 'difference between "perl" and "Perl"'

<OT>

No offense intended,
Michele
--
> Your right, I didn't think of that at all, but still, who's gonna go into
> the temp internet folder and create a cookie? At least not most users.
Of course *most* users aren't going to do that. *Most* users aren't
trying to hack your site! You don't program securely for *most* users -
you program securely for the few users who *are* trying to be malevolent.
- Paul Lalli in clpmisc, "Re: free source authentication script"