At 09:50 AM 2/20/2006 -0500, D D Allen wrote:
And then try to explain these lines -- why the first produces the output
10 and the second produces the output 30 -- which is not a Perl bug.
print (5*2)*3;
print "\n";
print 5*(2*3);
print "\n";
As Larry Wall says in the Came
At 09:50 AM 2/20/2006 -0500, D D Allen wrote:
>And then try to explain these lines -- why the first produces the output
>10 and the second produces the output 30 -- which is not a Perl bug.
>
>print (5*2)*3;
>print "\n";
>print 5*(2*3);
>print "\n";
Yep I
nusual function
(or an ordinary function in an unusual way). It could also involve treating
data that is typically seen as being one type as some other type, a view
that is permissible according to the language but not intuitive."
And then try to explain these lines
-- why the first produces the o
[snip ... why doesn't "my $i if 0;" generate a warning under "use
warnings;"]
Glenn Linderman wrote:
Partly because the behaviour was probably implemented unintentionally
(hence no original warning or error), and has been treated (once
discovered by those nefarious end-user types) as a feature
At 04:50 PM 2/17/2006, Robert May wrote:
my is a compile time directive that creates the lexically scoped $i,
giving is scope from its definition until the end of the enclosing block.
Assignment is a run time operation. In your example the modified
assignment doesn't get executed, so the valu
John Deighan wrote:
>> OK, then, consider this program. Notice that there's a global $i which
>> has the value 5. Now, when func() is called, if the "my $i" did not
>> create a new lexically scoped variable, then the print line would print
>> "i = 5". But it doesn't - obviously because the lexic
On Fri, 17 Feb 2006 12:05:08 -0800, you wrote:
>OK, then, consider this program. Notice that there's a global $i
>which has the value 5. Now, when func() is called, if the "my $i" did
>not create a new lexically scoped variable, then the print line would
>print "i = 5". But it doesn't - obvious
At 02:28 PM 2/17/2006 -0500, John Deighan wrote:
>That in no way explains where the values that end up in those
>variables come from. Also, see my other post about the creation of
>the lexical variables in statement like "my $var = if
>". If I'm wrong in that post, I'd like to know why.
They g
John Deighan wrote:
At 01:06 PM 2/17/2006, Joe Discenza wrote:
Fascinating! You have one misconception right off: The "my" line is
never executed (not even to make the new variables) if $L is false.
OK, then, consider this program. Notice that there's a global $i which
has the value 5. Now,
At 01:06 PM 2/17/2006, Joe Discenza wrote:
Fascinating! You
have one misconception right off: The "my" line is never
executed (not even to make the new variables) if $L is
false.
OK, then, consider this program. Notice that there's a global $i
which has the value 5. Now, when func() is called, if
At 01:29 PM 2/17/2006, Chris Wagner wrote:
At 12:46 PM 2/17/2006 -0500, John Deighan wrote:
>OK, same caveat as before - apparent bugs in Perl are usually user
>errors, but once again, I'm stumped. Here is my code. The problem I
>have is in the second call to getCached(), specifically, the line:
Title: RE: Perl Bug (again)
John Deighan wrote, on Fri 17-Feb-06 12:46
: my($nextID,$maxID) = @$L if $L;
:
: The parameter to getCached, $Customer, has a different value than
: during the first call. Because of that, the variable $L is undefined.
: What I expect the statement above to do is
At 12:46 PM 2/17/2006 -0500, John Deighan wrote:
>OK, same caveat as before - apparent bugs in Perl are usually user
>errors, but once again, I'm stumped. Here is my code. The problem I
>have is in the second call to getCached(), specifically, the line:
>
>my($nextID,$maxID) = @$L if $L;
I think
OK, same caveat as before - apparent bugs in Perl are usually user
errors, but once again, I'm stumped. Here is my code. The problem I
have is in the second call to getCached(), specifically, the line:
my($nextID,$maxID) = @$L if $L;
The parameter to getCached, $Customer, has a different value
At 06:53 PM 2/8/2006 -0800, Glenn Linderman wrote:
>My understanding is that in a file foo.pl
>
>my global_foo;
>sub counter { return global_foo++; }
>
>that sub counter is a closure, which probably is even further outside
>your thought processes-- I was surprised to learn that from Dave, but
>g
Glenn Linderman wrote:
On approximately 2/8/2006 1:06 PM, came the following characters from
the keyboard of Lyle Kopnicky:
Thanks for the explanation. As far as I am concerned, then, perl's
closure model is unintuitive and broken. It doesn't work like
closures in any other language I have se
At 09:10 AM 2/8/2006 -0800, Glenn Linderman wrote:
>So, $lTokens is a reference from a sub, to a variable declared outside
>of the sub (specifically, to the $lTokens declared in parse on its first
>invocation), thus making gettoken a closure and causing that
>instance of $lTokens to be prese
At 03:09 PM 2/8/2006, Glenn Linderman wrote:
Now that I understand the situation, I can offer the following as a
way to safely do what I was trying to do in the first place - by
creating an anonymous function and assigning it to a variable named
$gettoken, then calling it with the syntax &$ge
Glenn Linderman wrote:
So, $lTokens is a reference from a sub, to a variable declared outside
of the sub (specifically, to the $lTokens declared in parse on its
first invocation), thus making gettoken a closure and causing that
instance of $lTokens to be preserved as part of the state of th
OK
TOKEN: 3
TOKEN: *
TOKEN: 3
OK
TOKEN: '4'
TOKEN: *
TOKEN: 4
OK
Use of uninitialized value in concatenation
(.) or string at testtoken.pl line 5
0.
TOKEN: ''
ERROR: Empty Input
John Deighan <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
02/08/2006 09:40
At 12:10 PM 2/8/2006, Glenn Linderman wrote:
On approximately 2/8/2006 6:40 AM, came the following characters
from the keyboard of John Deighan:
I realize that most things that look like bugs in Perl are in
reality programmer bugs, but I can't figure out why the second call
to the function "par
This should illustrate what is going on:
use strict;
my $lTokens = [qw(2 * 2)];
print "1 before parse: ", $lTokens, "\n";
my $errmsg = parse($lTokens);
print($errmsg ? "ERROR: $errmsg\n" : "OK\n");
$lTokens = [qw(2 * 2)];
print "2 before parse: ", $lTokens, "\n";
my $errmsg = parse($lTokens);
pr
I realize that most things that look like bugs in Perl are in reality
programmer bugs, but I can't figure out why the second call to the
function "parse()" in the code below fails. According to my debugger
(from ActiveState's Perl Development Kit), the function parse() gets
a correct list of 3
23 matches
Mail list logo
