in reply to Re: Re: Re: Re: Surpised by foreach iterator limitation
in thread Surpised by foreach iterator limitation

Wrong.

use Data::Dumper;

%hash = (key => 1);
local $hash{key} = 2;

print Dumper(\%hash);# print 2
print $hash{key};# also print 2.

[download]
This clearly demos that $hash{key} is not another scalar, it simply refers to a hash element, which is a scalar. Again, please try to understand the subtle difference between "valid syntax to name an element of a collective, which happened to be a scalar", and "valid syntax for scalar name".

They will support it in Perl 5.10? Hope this will never happen ;-)

Let's look at from a different perspective. In c, you can say, 
int a[200];

[download]
You can also say, 
a[100] = 2;

[download]
but is a[100] a valid variable name? no, it is NOT. It can be used to call an array element, but it is not a valid variable name. It is the same situation here.

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Re: Surpised by foreach iterator limitation
by Anonymous Monk on Apr 08, 2003 at 04:34 UTC
    I think you are confusing yourself with arbitrary distinctions of exactly the kind that Perl cheerfully tramples over.

    By your reasoning I would predict that local should not work on a hash value - because local replaces a scalar with another scalar temporarily. But lo and behold, look at this! 

    use Data::Dumper;
%foo = qw(hello world);
print Dumper \%foo;
{
  local $foo{test} = "Just for now";
  print Dumper \%foo;
}
print Dumper \%foo;

    [download]
    What happened? Well take your pick. Either Perl doesn't agree with your distinction between "valid syntax to name an element of a collective" and "valid syntax for a scalar name" or else Perl is sometimes unusually willing to accept the former in places where one would expect the latter. (I lean towards the second interpretation - after all one cannot use my just anywhere, nor can one get that to make any sense.)

    Therefore if someone is willing to do the work and there is no ambiguity in the parsing, this feature could make it into Perl 5 and it wouldn't necessarily be a bad thing.

    Incidental note. One cannot use local on a lexical. This is an utterly arbitrary limitation - the feature was once put in only to be taken out because it was felt that where it happened it was undoubtably a mistake.

[reply]
[d/l]
Re: Re: Re: Re: Re: Re: Surpised by foreach iterator limitation
by MarkM (Curate) on Apr 08, 2003 at 03:38 UTC

    Wrong how? By suggesting that foreach() could work if suitably innovated? I don't see how this could be wrong. You are looking at the current implementation of foreach() and local() and declaring it impossible, unfeasible, or wrong. If everybody looked at Perl this way, there would be no Perl 6, let alone Perl 2.

    Please note that I didn't say the patch would be less than 100 lines long. Perl's evolution is entirely based on this sort of principle. People expecting something to 'just work'. It doesn't. People fix it so that it does. This is Perl. You should be familiar with this by now. :-)

    You seem to be stuck on the definition of 'variable'. Where you and the original poster differ is that you don't see a[5] as a variable. I and the original poster *do* consider a[5] to be a variable. Fine, it doesn't have a simple name, but then, who cares about simple names? Your example showing that local() has a wider scope is wrong, since I am sure you should realize that:

    package main;
local $b = 2;
$main::b = 3;
print "$b\n"; # prints "3\n"

    [download]

    Meaning, that '$b' is really just ${$main::{'b'}}, which is just as much a 'variable' or not a 'variable' as $a[5] is.

    I think I've made my case... :-)

[reply]
[d/l]
[select]
      No, I am not looking at the current implementation of Perl. I am looking at a very fundamental principle of the syntax for computer language:

      Any syntax should have a consistent meaning/interpretation, and can be consistently recognized by computer as a presentation of the same existance.
[reply]

In Section Seekers of Perl Wisdom