develooper Front page | perl.perl5.porters | Postings from November 2005

Re: [PATCH] sort/multicall patch

Thread Previous | Thread Next
From:
Robin Houston
Date:
November 5, 2005 03:58
Subject:
Re: [PATCH] sort/multicall patch
Message ID:
20051105115816.GA27642@rpc142.cs.man.ac.uk
On Sat, Nov 05, 2005 at 02:52:08AM +0000, Dave Mitchell wrote:
> * should PUSH_MULTICALL take the CV as an arg rather than implicitly using
> the cv variable?

That's a nice idea: perl's implicit use of local variables is not its
most delightful feature, in my view. :-)

The thing is that PUSHSUB already uses 'cv' implicitly. I could write

#define PUSH_MULTICALL(the_cv) STMT_START { \
	CV *cv = the_cv;				\
	/* etc */

but that ain't gonna work if you try and do PUSH_MULTICALL(cv),
which is after all a reasonable thing to try and do! I suppose
something like

#define PUSH_MULTICALL(the_cv) STMT_START { \
	CV *_tHerEAlActuaLcV_ = the_cv;		\
	CV *cv = _tHerEAlActuaLcV_;		\
	/* etc */

might be okay, but I'm not enough of a C language lawyer to be sure.
I know GCC is cool with it, but is it *guaranteed* to be all right
to have two variables with the same name defined in the same function?

> * pp_sort() isn't using these macros. Will this change later, or are there
> reasons why it can't?

One issue is that pp_sort() doesn't necessarily have a CV. If you
use a sort block, like  sort { f($a) cmp f($b) } @foo , then the
code for the block just sits in the optree rather than its own CV.

Robin

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About