in reply to Re^3: Contexts and Perl 6
in thread Contexts and Perl 6

So, you go through all the trouble of cloning the closures and creating the one-off "butted" type. Even if inlined or the compiler otherwise does know the context, it still can't easily figure out that whole methods can be removed.

If the function knew it was called in numeric context, it could return Array but compute_length();. If optimized over, the property contains no closures, so is easily cut down to just the desired function call.

Replies are listed 'Best First'.
Re^5: Contexts and Perl 6
by moritz (Cardinal) on May 18, 2009 at 21:23 UTC
    Even if inlined or the compiler otherwise does know the context, it still can't easily figure out that whole methods can be removed.
    Why not?
[reply]
      The blocks might end up calling each other or otherwise using self and then the ramifications are not easily tracked.

      I like it in principle, but give it a more formal construct that includes the promise that no more than 1 of them will be asked for and they are not interdependant. Said construct could also help with syntactic sugar if the final way of writing the contexualizer methods isn't quite so pretty (simple method names easily conflict with regular use; it's a shame to reserve them).

      —John

[reply]
[d/l]
        The blocks might end up calling each other

        That doesn't matter if they're not called.

        I like it in principle, but give it a more formal construct that includes the promise that no more than 1 of them will be asked for and they are not interdependant.

        IMHO that's a (premature) optimization that can be added later, when a compiler actually wants to do such an optimization, via a trait or so.

        That said, if somebody comes up with a nice syntax for them, why not?

[reply]

In Section Meditations