Re: why does push not default to $

print has a quite complex signature. It must distinguish between print $this; and print TO_THIS;, for example. So it also can tell between print @empty; and print;.

push is quite simple. You can write your own sub that offers the exact same interface:

sub Push(\@@);
[download]

So what to push onto the array is simply a (flattened) list (of scalar values). So push can't tell the difference between push @a; and push @a, @empty;... unless its simple interface gets special-cased for this. I'm not surprised that such special-casing was not deemed worth allowing the questionable usage of an implied $_.

At some point, somebody did some extra work to add the warning you get. The code you want would be added at the same point, but it would have to synthesize code to push the current value of $_ onto the stack before the push opnode (or thereabouts). That is certainly more work than just emitting a warning.

But then you'd have to fight the backward-compatibility battle -- which, frankly, I would consider a rather silly battle since transforming something that is useless and emits a warning into something useful (but perhaps of dubious wisdom) seems quite reasonable regarding backward compat.

- tye

Comment on Re: why does push not default to $_? (simple) Select or Download Code

Replies are listed 'Best First'.
Re^2: why does push not default to $_? (simple) by LanX (Saint) on Dec 05, 2008 at 09:41 UTC
Am I understanding you right, the prototyope mechanism of builtins like push can't distiguish between missing parameters and empty parameters. But some special functions like "print" and "splice" have a proper non-prototype-based interface? () I'm not really missing that feature, it's just a meditation about design and orthogonality. IMHO, it would be much easier to prog if perl had more axiomatic rules instead of a bunch of special exeptional cases. Something like "if the last obligatory list @ or scalar $ in a prototype is ommitted in the code, $_ will be included instead throwing an error". Or as more flexible approach "you can use "@_" and "$_" in prototypes to flag parameters which default to $_ if missing" ² anyway, perl6's solution to flag these functions with a trailing . and making them methodes of an invisible $_ seems reasonable! (eg `.print; .push @a;`) Cheers Rolf UPDATES: () Must be! That's why prototype returns undef for print and split, showing they are not overridable! `DB<10> use Data::Dumper DB<11> print Dumper prototype "CORE::split" $VAR1 = undef; DB<12> print Dumper prototype "CORE::print" $VAR1 = undef; DB<13> print Dumper prototype "CORE::push" $VAR1 = '\\@@';` [download] (²) But I don't know if it makes sense to push a global like $_ on the stack...	[reply] [d/l] [select]
Re^3: why does push not default to $_? (simple) by JadeNB (Chaplain) on Dec 05, 2008 at 22:30 UTC
Or as more flexible approach "you can use "@_" and "$_" in prototypes to flag parameters which default to $_ if missing" Is this a claim (that you can already do this) or a suggestion? If it's a claim, then note that `_` is already a valid character in prototypes for a scalar argument defaulting to `$_`, as you want. If it's a suggestion, then I think that having a prototype syntax like `@_` would be very confusing (besides being ambiguous, given that it conflicts with a currently valid, although useless, prototype), since `@_` already has a quite different meaning. By the way, notice that Params::Validate has a very rich defaults syntax for this sort of thing. In particular, you can do something like `validate_pos 1, ( { default => $_ } ) x ( @_ - 1 )` [download] UPDATE: Oops, that last snippet doesn't make any sense. Indeed, as I think about it further, what does it mean to have an array of values, all of which default to `$_` if absent? I think it's best to stick with the case of allowing explicitly listed parameters to default: `validate_pos 1, ( { default => $_ } ) x 57` [download]	[reply] [d/l] [select]
Re^4: why does push not default to $_? (simple) by LanX (Saint) on Dec 05, 2008 at 22:59 UTC
it's a meditation! > that _ is already a valid character in prototypes for a scalar argument defaulting to $_, as you want. well, couldn't find it in the docs perlsub ... ups ...I was scanning the text und examining the examples and tables, but after a textsearch for "_" there is a somehow hidden phrase: As the last character of a prototype, or just before a semicolon, you can use _ in place of $ : if this argument is not provided, $_ will be used instead. wow, it's already implemented! ~~So its possible to override CORE::push with `sub push(\@_;@)`, which will default to $_ if the list is omitted!~~ ~~That means there is no technical reason that it's not already implemented this way, it's just Larry's decission.~~ UPDATE Thats wrong, see following post... This thread is really instructive ... thanx! : ) Cheers Rolf	[reply] [d/l]
Re^5: why does push not default to $_? (simple) by LanX (Saint) on Dec 06, 2008 at 02:00 UTC
Re^6: why does push not default to $_? (simple) by JadeNB (Chaplain) on Dec 07, 2008 at 18:13 UTC
Some notes below your chosen depth have not been shown here


XP is just a number
	PerlMonks

Re: why does push not default to $_? (simple)