Re: Perl oddities

system returning true on failure, false on success. I know why it's doing that, I know where it's coming from (and that's why), but it still makes me gag each and every time I use it.
open not returning a file handle, but modifying its first argument. There are other functions modifying their first argument (push and friends, 4-arg substr, chomp/chop), but you kind of expect those. open doing so seems to do it for no other reason of mimicing the underlaying C functionality.
Perl has every important flow control keyword used by other important languages, and then some. But it doesn't have a (native) switch. Or rather, it still doesn't have one. While it was on the wishlist of perl 1.0.0.
Ok, so Perl has this IO system that used to be a thin layer over your systems IO system, and now (with PerlIO) mimics it, but still looks the same. And while I can easily lock entire files, why can't I easily lock file regions on systems that support it?

perl -wce 'chomp ($_)'
-e syntax OK
perl -wce '$_ = log ($_)'
-e syntax OK
perl -wce 'print ($_)'
print (...) interpreted as function at -e line 1.
-e syntax OK
perl -wce 'print  ($_)'
-e syntax OK
[download]

Warn (wrongly) for one particular function, if you have exactly one space between the function name and the opening paren?

Comment on Re: Perl oddities Download Code

Replies are listed 'Best First'.
Re^2: Perl oddities by TimToady (Parson) on Mar 01, 2005 at 18:51 UTC
Now that Perl 6 has interesting values of undef, it's easy to fix `system`, though we will probably rename it just to avoid confusion. Make it `sysrun`, or maybe just `run`. `open` returns a filehandle object in Perl 6. Perl 6 will have a switch statement because we finally figured out how it relates to smart matching and topicalization and exception handlers. The IO system for Perl 6 will be truly OO and not just made to look that way like Perl 5 did. So it'll be fairly easy to have whatever odd methods you like on derived IO classes, including regional locking. The parsing rules for function parentheses have been regularized in Perl 6, though not necessarily to everyone's delight. `;-)`	[reply] [d/l] [select]
Re^2: Perl oddities by Tanktalus (Canon) on Mar 01, 2005 at 16:58 UTC
system returning true on failure, false on success. I know why it's doing that, I know where it's coming from (and that's why), but it still makes me gag each and every time I use it. I think Larry realises this. I'm hoping that Perl6's system function knows to do something like `return $rc but ! $rc`. Then 0 would be true and non-zero would be false, when checked in boolean context, but the return code would still be available: `my $rc = system(...); unless ($rc) { print "system failed with rc = $rc!\n"; }` [download] (Or something like that - my perl6 isn't rusty, it's just not there yet ;->)	[reply] [d/l] [select]
Re^3: Perl oddities by Joost (Canon) on Mar 01, 2005 at 17:03 UTC
IMO system() (and related ops) should just raise an exception on error. There is no reason to force everyone to write all these return code checks when 90 % of the time you'll want to bail out on error anyway (and if not, you can use eval, or try() in perl6). "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re^2: Perl oddities by Mugatu (Monk) on Mar 01, 2005 at 17:04 UTC
But it doesn't have a (native) switch. No fair, picking on explicit design decisions. :-) Warn (wrongly) for one particular function What's wrong about the warning? It's there to prevent the common pitfall of expecting things like this to work right: `print (stat)[9];` [download] And seems like a perfectly reasonable warning. Many other warnings are special-cased and very specific, so I don't know why you chose this one. Update: I didn't realize the warning would trigger with one and only one space. That does seem kind of peculiar. But if that was the crux of what the OP was talking about, it wasn't exactly clear.	[reply] [d/l]
Re^3: Perl oddities by QM (Parson) on Mar 01, 2005 at 23:55 UTC
What's wrong about the warning? It's there to prevent the common pitfall of expecting things like this to work right: `print (stat)[9];` [download] His point was the warning cares about exactly one space. Why it shouldn't it give the same warning for these also? `print(stat)[9] print (stat)[9]` [download] is obtuse. I'm sure there are a hundred root nodes on this site alone about abuse of white space, so I'll defer to them. -QM -- Quantum Mechanics: The dreams stuff is made of	[reply] [d/l] [select]
Re^3: Perl oddities by Anonymous Monk on Mar 02, 2005 at 13:09 UTC
As noted, I find the oddity in that it warns about exactly one space - althought it doesn't do that always: `perl -wle 'print ("foo")' # Warning perl -wle 'print ("foo");' # No warning perl -wle 'print (")");' # Warning perl -wle 'print ("\x29");' # No warning` [download] Now, I know why it's happening (I've studied the source), and I also know what the intent is, but that's beside the point. `brian` asked about oddities, and I do find this an oddity. But the single space is not the only thing that I find an oddity. I also find it odd (as in, irregular, different that you would expect based on how similar constructs are handled - you know, what `brian` was asking for - so spare me the explainations on why it is this way - I know already) that is only has these warnings for `print` and I think one other function. For other functions, it doesn't warn. `$ perl -wle 'print ("foo") . "bar"' print (...) interpreted as function at -e line 1. Useless use of concatenation (.) or string in void context at -e line +1. foo $ perl -wle 'my $s = length ("foo") . "bar"'` [download] Why warn only with print and a single space, but not with `length` or other functions? Or other amounts of whitespace? That I find an oddity.	[reply] [d/l] [select]
Re^2: Perl oddities by theorbtwo (Prior) on Mar 02, 2005 at 12:04 UTC
Re the last one, it should simply be gotten rid of. The reason it's there is to keep you from accidentally saying `print (1+2)/3;`. That now gives /both/ a useless use of division in void context and a print interpreted as function. The "print interpreted as function" was there long before the "... in void context"; the later is more useful, but was harder for perl to notice. Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).	[reply] [d/l]


Keep It Simple, Stupid
	PerlMonks