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

Re: [perl #100190] RFE: fix sprintf to be consistent with printf and be useful!

Thread Previous | Thread Next
From:
Linda Walsh
Date:
November 11, 2011 15:33
Subject:
Re: [perl #100190] RFE: fix sprintf to be consistent with printf and be useful!
Message ID:
4EBDB0B8.80004@tlinx.org
Nicholas Clark via RT wrote:

> On Wed, Oct 05, 2011 at 05:20:17PM -0700, Father Chrysostomos via RT wrote:
...


> I think we're all agreeing, and I'd like to add to it:
...
> Prototypes were added (if I understand it correctly) mainly to permit one to
> define functions that behaved like core builtins. The core's parser doesn't
> use prototypes to parse the builtins.
... 
> Changing the "prototype" of a core builtin for the intent of changing
> behaviour doesn't actually mean changing the prototype. That's a derived
> property. It actually means changing the parser. Changing the parser is quite
> possible. But it's not just "a function in isolation".
> 
> So I think it's important to realise what level the change is actually at.
> 
> Nicholas Clark

----
	So question(s) then:

In something like push, where $p is a pointer to an array,
would it be a change to the prototype or the behavior to
have  "push $p,<list>" work, w/o using "push @$p,<list>" (or
in some cases "push @{$p},<list>"?

2nd (which started this) in sprintf,
to get the sprintf to behave like part after
the optional IOh in printf, i.e.
printf [handle] (list), where 1st arg is interpreted as a format...

so instead of
sprintf <listitem>,<list> (where generally:
				list = <listitem>,<list>
				listitem = <listitem | "" >
			)
we could just use
sprintf <list>, and have sprintf _behave_ the same, but not
have the parser throw a cow^h^h^hwarning, about a syntax problem?

^^ Would that be a change in the prototype, or a change in the
behavior?

(I guess it means what level of the interpreter one is talking about,
but conceptually, I don't see behavior of either being changed, just how
they are parsed).  If the were normal functions, it would be a matter of
changing sprint ($@) to (@)

and push from ($@)...


@ run time, doesn't matter if you put '@' in front of '$p' or not,
if $p isn't a ref to an array...you still get 'not an array ref at xx'...

so execution, I would think, would catch things the same way as
always.

in the case of sprintf (foobar(),@_), I can think of no
reason, other to demonstrate 'kinky code' of having foobar
return different things based on context of 'wantarray',
despite the fact, that this would break:

perl -E  '
sub foobar {
   state $counter=0;
   my @answers=(3,2,42);
   unless (wantarray) {return !@answers?"":"%d".(", %d" x $#answers)."\n"}
   else { return $answers[$counter++] }
}
print sprintf foobar(),foobar(),foobar(),foobar();'
3, 2, 42
----
despite being able to use a greater than or equally perverse:

perl -E  '
sub foobar {
   state $counter=0;
   my @answers=(undef,3,2,42);
   $answers[0] = !$#answers ? "" : "%d" . ", %d" x ($#answers-1) . "\n";
   $answers[$counter++];
}
print sprintf foobar(),foobar(),foobar(),foobar();'
3, 2, 42

Neither of which would belong in any book on programming style
and clarity.  So how likely is it, that the first would be used and
be important enough not to fix the wart#2?





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