On Tue, 2008-02-12 at 12:46 -0500, Bob Rogers wrote: > From: Andrew Parker <[EMAIL PROTECTED]> > Date: Tue, 12 Feb 2008 15:17:03 +0100 > > Thanks for the pointer, Bob. I read through it and it might be > tangentially related to this. That problem is about scopes being > modeled by subs in parrot. IMHO there is not a great problem there, > since a sub is really an abstraction for entering and leaving a scope > and so a good abstraction for what is being done. > > I tend to disagree. I think of subs as equivalent to HLL procedures. > When the compiler has to split the user's expression of the problem into > multiple subs, that can only make it harder to debug. But I've already > been overruled on this, and don't want to reopen the issue.
This interests me as much from a performance point of view as a theoretically purity view. In Perl 5, scopes are slow, and subs are REALLY slow. In my performance-critical code, I often have to lose some cleanliness by manually inlining multiple small subs into a calling sub's loop. And if that's not enough, I have to do gymnastics with the code to avoid as many scopes inside the loop as possible. Heck, I've even written source filters that convert a tree of method calls into one horrid inlined mess, just to squeeze out another doubling of performance before I have to resort to C code. I was really looking forward to using Perl 6 features to inline the small subs for me (with no nasty source filtering hell), so that I could keep clean, well-factored source code and still run fast (enough). But if every Perl 6 scope gets turned into a separate sub under the covers, that inlining is going to have to be mighty smart to avoid creating new scopes, and therefore new subs, and therefore saving exactly nothing performance wise. Feh. Please someone tell me there is a light at the end of this tunnel? -'f
