Re: RFC 212 (v1) Make length(@array) work
"Perl6" == Perl6 RFC Librarian [EMAIL PROTECTED] writes: Perl6 Make length(@array) work Perl6 I propose to make length() return the number of elements in the array Perl6 it is passed, if its first argument begins with @. This proposal makes length() an un-prototypable (and therefore unoverridable). Do you have a proposal for how to handle that? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: RFC 212 (v1) Make length(@array) work
Randal L. Schwartz writes: This proposal makes length() an un-prototypable (and therefore unoverridable). Do you have a proposal for how to handle that? Do we really want everything in Perl to be overridable? What use is an overridden length()? Nat
Re: RFC 212 (v1) Make length(@array) work
On Wed, 13 Sep 2000, Hildo Biersma wrote: =head1 TITLE Make length(@array) work Counter-proposal: make length(@array) a syntax error. I don't feel like rewarding stupidity, I'd rather teach people how to do things properly. As a general rule, I agree with Hildo that we shouldn't reward stupidity. However, the beautiful thing about Perl, the thing that makes me prefer it over every other language on the planet, is that it generally DWIMs. For the most part, the natural, intuitive thing works (ok, first you have to wrap your head around context and a few other bits of weirdness, but THEN it's intuitive). So I ask...if many newbies do this, and not all of them are stupid (a very safe statement, statistically), then perhaps this is simply an example of "the intuitive way to do it" and we should make it work? Dave
Re: RFC 212 (v1) Make length(@array) work
Nathan Wiger writes:
Brainstorming off the top of my head:
sub length (($|@)) {
}
That is, use a regex-like "(x|y)" - or maybe [$@%] ?? - for alternative
context coercions.
The only RFC on prototype extensions we have is Andy Wardley's #57.
I suggest you ask him to add this feature.
Nat
Re: RFC 212 (v1) Make length(@array) work
Casey R. Tweten writes:
Ok, consider allowing:
$a = length @b;
to DWIM, however, when running with warnings, warn the user that Cscalar is
what they really want.
Just thowing that out there.
Good idea, but I think it's a bad move to turn warnings into style
guides. Warnings should point out things that have unexpected
consequences ("you seemed to think that value was defined, but it
wasn't", "that parenthesis after the function name is interpreted as
starting the argument list, but you put whitespace between the
function name and the parenthesis--you're not thinking the parentheses
are giving you a term in a larger expression, are you?"). They should
be things that you pay attention to because your program is probably
wrong.
Turning Perl into a nagging harpie means that the really important
warnings will be ignored.
This line of thinking brought to you by Mark-Jason's excellent talk
on data typing.
Nat
Re: RFC 212 (v1) Make length(@array) work
Today around 12:19pm, Nathan Torkington hammered out this masterpiece:
: Casey R. Tweten writes:
: Ok, consider allowing:
:
:$a = length @b;
:
: to DWIM, however, when running with warnings, warn the user that Cscalar is
: what they really want.
:
: Just thowing that out there.
:
: Good idea, but I think it's a bad move to turn warnings into style
: guides. Warnings should point out things that have unexpected
: consequences ("you seemed to think that value was defined, but it
: wasn't", "that parenthesis after the function name is interpreted as
: starting the argument list, but you put whitespace between the
: function name and the parenthesis--you're not thinking the parentheses
: are giving you a term in a larger expression, are you?"). They should
: be things that you pay attention to because your program is probably
: wrong.
:
: Turning Perl into a nagging harpie means that the really important
: warnings will be ignored.
:
: This line of thinking brought to you by Mark-Jason's excellent talk
: on data typing.
I agree with this line of thinking, however, I suppose I don't agree with
implementing length in this way since we already have Cscalar.
In that light, if Clength is to replace scalar for, we'll say, LISTs, then
lets remove Cscalar since it will be effectivley defunct.
Using length like will DWIM when a beginning perl hacker sits down after
learning C or JavaScript or Java or [ fill in the blank ].
--
print(join(' ', qw(Casey R. Tweten)));my $sig={mail='[EMAIL PROTECTED]',site=
'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig-{site})+6),"\n";
print map{$_.': '.$sig-{$_}."\n"}sort{$sig-{$a}cmp$sig-{$b}}keys%{$sig};
my $VERSION = '0.01'; #'patched' by Jerrad Pierce belg4mit at MIT dot EDU
Re: RFC 212 (v1) Make length(@array) work
"Casey" == Casey R Tweten [EMAIL PROTECTED] writes: Casey I agree with this line of thinking, however, I suppose I don't Casey agree with implementing length in this way since we already Casey have Cscalar. Casey In that light, if Clength is to replace scalar for, we'll Casey say, LISTs, then lets remove Cscalar since it will be Casey effectivley defunct. Uh, no. It provides a scalar context. For only a few kinds of things that return lists in lists context, do they return the LENGTH of that list in a scalar context. Most other things have much more interesting return values in a scalar context, and a few have nothing but undef. I just had this discussion on Usenet... please go Deja comp.lang.perl.misc. In fact, you can't get "scalar" in front of a list. It doesn't exist. It can't *ever* exist. This also means that length X is not the same as length scalar X but rather, specialcased VERY SPECIFICALLY for length @FOO This is what I don't like about this proposal. It raises more eyebrows than it fixes. I like the suggestion that it be a warning, and leave it at that. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: RFC 212 (v1) Make length(@array) work
This proposal makes length() an un-prototypable (and therefore
unoverridable). Do you have a proposal for how to handle that?
Pray to Damian for a prototype that supports this? :-)
If you'd been studying the holy writings properly, young Torkington,
instead of those wicked magazines under your bed, you'd be familiar with
RFC 128, specifically:
http://tmtowtdi.perl.org/rfc/128.html#Context_classes
Should that epistle find favour in Larry's eyes, the specification
of the proposed modification to Clength would be:
sub length ([\@$]) { ... }
;-)
Damian
Re: RFC 212 (v1) Make length(@array) work
The only RFC on prototype extensions we have is Andy Wardley's #57. Except, of course for #128, which already covers it. ;-) Damian
Re: RFC 212 (v1) Make length(@array) work
Who has time to read all the crap you write, Damian? :-) Indeed. ;-) Sorry I missed that one. Thanks for pointing it out. I've just submitted an updated version which will probably hit the archive in the next few hours. For those who can't wait, the latest versions of all my RFCs are always available (in POD format only) from: http://www.csse.monash.edu.au/~damian/Perl/RFC/ The particular one under discussion here is: http://www.csse.monash.edu.au/~damian/Perl/RFC/RFC_subroutineParamLists Damian
Uninitialized value warnings should die (was Re: RFC 212 (v1) Make length(@array) work)
Nathan Torkington wrote:
Turning Perl into a nagging harpie means that the really important
warnings will be ignored.
This line of thinking brought to you by Mark-Jason's excellent talk
on data typing.
I agree, and just read MJD's paper the other day (nice job, BTW), but
unfortunately there are a couple warnings that are really on the edge of
nagging already, specifically:
Use of uninitialized value in concatenation (.) at line 32
Brought to you by the lovely:
print "Welcome back, $first $middle $last!\n";
How neat. Who else hates this? It's enough to drive me batty, and smacks
of the useless typecasts needed to shut C up.
Thankfully, Perl 5.6 allows you to say:
no warnings 'uninitialized';
But unfortunately you then have to block this off:
{
no warnings 'uninitialized';
print "$some $stuff\n";
}
Or put it in your whole code up at the top, in which case you miss out
on potentially useful uninitialized variable warnings just to maintain
your sanity (or make your CPAN module look clean).
My question: What good is this warning in most contexts, anyways?
Really. Honestly. If you cared about the value, you would already be
checking it, right? Probably with something like this:
die "Fatal: Can't continue with \$var unset!" unless $var;
Perl should stop nagging about this. Perl should be smart and not bother
you about uninitialized values in the following situations:
- string concat
- string comparison
Warning me that in:
$z = $x + $y;
$z = --$x;
do_stuff() unless ($x 5);
$x is uninitialized is probably a good idea, because of the nature of
numeric ops. But telling me:
$name = $NAME unless ($name eq $local_name);
$name is uninitialized in the string eq is a waste. These warnings just
annoy, since in order to take advantage of them you have to put explicit
catches in your code anyways, like:
$name = $NAME unless ($name eq $local_name);
die "Fatal: Couldn't determine name!" unless $name;
And notice this is at a completely different logical point than the
warning would harp at. That's my($.02), if anyone agrees I'll write an
RFC (but I suspect my legs are about to be cut off :).
-Nate
