Re: RFC 212 (v1) Make length(@array) work
On Tue, 19 Sep 2000 07:40:07 -0700 (PDT), Dave Storrs wrote: Doesn't this reflect C's idea of "a string is an array of characters"? Which isn't the idea behind strings in Perl. The basic idea is wrong. Therefore, making length(@array) work, would be a wrong signal. I personally do not see the connection, but even if I did I would still respectfully disagree. I'm not sure if you really disagree. You said: That means that (1) anyone who does _not_ have C experience will not have this problem, Are you saying that only people with experience in C will have this problem, or is this what you disagree with? Because this is precisely the argument I have against it. What I said was: making length(@array) "work" would be catering to novice people *coming from C*. We shouldn't. Not that much. In Perl, a string is not an array. The argument against my reasoning would be if the bulk of people making this mistake are *not* coming from C. I don't know. -- Bart.
Re: RFC 212 (v1) Make length(@array) work
What I said was: making length(@array) "work" would be catering to novice people *coming from C*. We shouldn't. Not that much. In Perl, a string is not an array. I'm pretty sure it's not just the people coming from C who expect this. This all points to the bug^H^H^Hdubious feature which is the sub($) context template as applied to named arrays and hashes. Requiring an explicit conversion would help a lot. Or so it seems. --tom
Re: RFC 212 (v1) Make length(@array) work
On Wed, 20 Sep 2000, Bart Lateur wrote: The argument against my reasoning would be if the bulk of people making this mistake are *not* coming from C. I don't know. I have a feeling we're either arguing the same side without realizing it, or we're just having a straight-up conversational rift. Let me restate my opinion and see if that helps: @a = (1, 2, 3); print (length @a); The result should be that 3 is printed. The concept of "(# of elements in array) == (length of array)" is a common one in many languages. It is intuitive to many people...I know that I tried doing it when I first started using Perl. It does not seem to particularly interfere with existing semantics (although, I'm sure someone will point something out that I have not considered)...by which I mean that "length @foo" does not currently have any frequently-used meaning. I like Perl because it generally DWIMs. This seems like a good way to make it DWIM more. Dave
Re: RFC 212 (v1) Make length(@array) work
On Wed, 20 Sep 2000 07:03:33 -0600, Tom Christiansen wrote: I'm pretty sure it's not just the people coming from C who expect this. Uh-oh. This all points to the bug^H^H^Hdubious feature which is the sub($) context template as applied to named arrays and hashes. Requiring an explicit conversion would help a lot. Or so it seems. I think you've nailed it on the head. I've tested it, and you can't use a generic list for arguments: print length(@a, 'this is a string'); -- Too many arguments for length at test.pl line 2, near "'this is a string')" Execution of test.pl aborted due to compilation errors. So length is already picky on what it accepts. You need to turn it into print length(scalar(@a, 'this is a string')); to get perl to accept it. Let's just make length()-- and all other functions with ($) as proptotype -- reject hashes and arrays. Those are currently probably the only weird things, that it does accept. -- Bart.
Re: RFC 212 (v1) Make length(@array) work
"Bart" == Bart Lateur [EMAIL PROTECTED] writes: Bart So length is already picky on what it accepts. You need to turn it into Bart print length(scalar(@a, 'this is a string')); Bart to get perl to accept it. And then what it's accepting is the scalar-comma operator, giving you the length of "this is a string". Not 2. Not the length of "2". :) -- 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
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.
What do you do when someone wants
$bytes = length Some_File_Handle;
or
$files = length Some_Directory_Handle;
or
$bytes = length Some_Directory_Handle;
or
$blocks = length Some_Directory_Handle;
--tom
Re: Uninitialized value warnings should die (was Re: RFC 212 (v1) Make length(@array) work)
On Wed, 13 Sep 2000 19:57:28 -0700, Nathan Wiger wrote: 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 Allow me to disagree. In my case, I mostly use variables in output (= used as strings), far less in numerical context, and these warnings tell me that there are some situations that I had overlooked in my script. Most of the time, ignoring these warnings would make me rely on incorrect results. -- Bart.
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
