[32355] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 3622 Volume: 11

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Feb 24 16:09:26 2012

Date: Fri, 24 Feb 2012 13:09:09 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)

Perl-Users Digest           Fri, 24 Feb 2012     Volume: 11 Number: 3622

Today's topics:
    Re: a question about efficiency <ben@morrow.me.uk>
    Re: a question about efficiency <kiuhnm03.4t.yahoo.it>
    Re: a question about efficiency <ben@morrow.me.uk>
    Re: a question about efficiency <rweikusat@mssgmbh.com>
    Re: a question about efficiency (Seymour J.)
    Re: a question about efficiency <kiuhnm03.4t.yahoo.it>
    Re: a question about efficiency <derykus@gmail.com>
    Re: a question about efficiency <kiuhnm03.4t.yahoo.it>
    Re: Constructing a value beforehand (Seymour J.)
    Re: tree to array of arrays <kiuhnm03.4t.yahoo.it>
    Re: tree to array of arrays <nospam.gravitalsun@hotmail.com.nospam>
    Re: tree to array of arrays <willem@toad.stack.nl>
    Re: tree to array of arrays <m@rtij.nl.invlalid>
    Re: tree to array of arrays <kiuhnm03.4t.yahoo.it>
    Re: tree to array of arrays <nospam.gravitalsun@hotmail.com.nospam>
    Re: tree to array of arrays <nospam.gravitalsun@hotmail.com.nospam>
    Re: tree to array of arrays <ben@morrow.me.uk>
    Re: tree to array of arrays <rweikusat@mssgmbh.com>
    Re: tree to array of arrays <nospam.gravitalsun@hotmail.com.nospam>
    Re: tree to array of arrays <kiuhnm03.4t.yahoo.it>
    Re: tree to array of arrays (Tim McDaniel)
    Re: tree to array of arrays <nospam.gravitalsun.antispam@hotmail.com.nospam>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Fri, 24 Feb 2012 11:17:42 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: a question about efficiency
Message-Id: <m78k19-r902.ln1@anubis.morrow.me.uk>

Quoth Kiuhnm <kiuhnm03.4t.yahoo.it>:
> On 2/23/2012 2:08, Ben Morrow wrote:
>
> > No, you're not. For efficiency reasons, perl doesn't entirely
> > distinguish between this case
> >
> >      my $x;
> >      for (1..2) {
> >          sub { $x }
> >      }
> >
> > and this case
> >
> >      for (1..2) {
> >          my $x;
> >          sub { $x }
> >      }
> >
> > so it has to create a full closure in both cases. In principle it could
> > work out that in the first case $x is in a section of code that will
> > only run once, and treat it as a global, but that information isn't
> > available at the point where it decides which form of anon sub it needs.
> 
> Then we should probably take "sub { $x }" out of the loop (in real-world 
> programs, I mean).

Perhaps, if you thought it mattered. It doesn't, usually.

> > (Incidentally, this issue came up here just the other day in the context
> > of 'variable will not stay shared' warnings, which are of course very
> > closely related. In that situation perl treats the second case as though
> > it were the first, rather than the other way around.)
> 
> I'm a little lost here.
> Every closure captures the same instance of $x in the first case.
> If I write
>    say &$_ for map { my $x; sub { ++$x } } (1..10)
> and
>    my $x;
>    say &$_ for map { sub { ++$x } } (1..10)
> I expect to get different results.
> But I probably miss some context here.

I was being unclear. 'Variable will not stay shared' is the warning you
get when you close a *named* sub over a variable which will have more
than one instance. Since a named sub only ever has one instance they
obviously all end up referring to the same variable, which ends up not
being shared with the outer scope any more.

However, because perl loses track of the difference between the two
cases above, it has to choose whether to warn for neither or both. Since
this is a warning, rather than an question of correctness, a false
positive is worse than a false negative, so it fails to warn in the
second case.

Ben



------------------------------

Date: Fri, 24 Feb 2012 12:24:46 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: a question about efficiency
Message-Id: <4f47737d$0$1374$4fafbaef@reader1.news.tin.it>

On 2/24/2012 12:17, Ben Morrow wrote:
> I was being unclear. 'Variable will not stay shared' is the warning you
> get when you close a *named* sub over a variable which will have more
> than one instance. Since a named sub only ever has one instance they
> obviously all end up referring to the same variable, which ends up not
> being shared with the outer scope any more.
>
> However, because perl loses track of the difference between the two
> cases above, it has to choose whether to warn for neither or both. Since
> this is a warning, rather than an question of correctness, a false
> positive is worse than a false negative, so it fails to warn in the
> second case.

Ok, now it's clear.

Kiuhnm


------------------------------

Date: Fri, 24 Feb 2012 11:23:36 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: a question about efficiency
Message-Id: <oi8k19-r902.ln1@anubis.morrow.me.uk>


Quoth gbacon@hiwaay.net (Greg Bacon):
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> : Greg Bacon writes:
> :
> : > Yes, there's always an outer scope, but that's relevant only when
> : > the sub needs to close over outer lexicals. [See the implementation
> : > of Perl_cv_clone in pad.c. (Important snip restored! -geb)]
> : 
> : But the fact that there is always a lexical scope implies that
> : subroutines are never without a lexical environment and that this is
> : consequently not a distinctive quality in Perl.
> 
> If a sub has no way of reaching into that lexical environment, then the
> distinction is irrelevant. See the implementation of Perl_cv_clone in
> pad.c.

The CvOUTSIDE links are still there, and perl goes to some trouble to
keep them valid. See pad_findlex and the implementation of eval:

    perl -E'my ($x, $y, $z) = (1,2,3);
        sub foo { say eval $_ for qw/$x $y $z/ }
        foo'

Ben



------------------------------

Date: Fri, 24 Feb 2012 14:36:13 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: a question about efficiency
Message-Id: <87d394xpr6.fsf@sapphire.mobileactivedefense.com>

gbacon@hiwaay.net (Greg Bacon) writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> : Greg Bacon writes:
> : > Yes, there's always an outer scope, but that's relevant only when
> : > the sub needs to close over outer lexicals. [See the implementation
> : > of Perl_cv_clone in pad.c. (Important snip restored! -geb)]
> : 
> : But the fact that there is always a lexical scope implies that
> : subroutines are never without a lexical environment and that this is
> : consequently not a distinctive quality in Perl.
>
> If a sub has no way of reaching into that lexical environment, then the
> distinction is irrelevant. See the implementation of Perl_cv_clone in
> pad.c.

Steele defines closure as 'function defined in a non-null lexical
environment'. Originally, I suggested to use the same definition for
Perl. But this definition cannot be used for Perl because it is not
possible to create a Perl subroutine which is outside of any lexical
environment aka 'outer scope'. And 'the implementation of
Perl_cv_clone' doesn't figure here at all: Irregardless of how
closures are implemented in Perl (meaning, even if there wasn't always
an outside link => Ben's posting), there's still always such an
outside environment when the subroutine is created.


------------------------------

Date: Thu, 23 Feb 2012 22:15:53 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: a question about efficiency
Message-Id: <4f4700e9$2$fuzhry+tra$mr2ice@news.patriot.net>

In <4f46a454$0$1388$4fafbaef@reader2.news.tin.it>, on 02/23/2012
   at 09:40 PM, Kiuhnm <kiuhnm03.4t.yahoo.it> said:

>Indeed, I've just found out that I can't use wildcards in
>command-line  arguments because Perl expects the shell to expand
>them, whereas Windows expects *the program* to expand them.

That's an oversimplification. There's nothing in Perl that prevents an
argument from containing wild cards, it's possible to escape wildcards
in the *ix shells and there are other systems besides windoze where
the shell doesn't interpret wildcard characters. See, e.g., glob EXPR
in perlfunc.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org



------------------------------

Date: Fri, 24 Feb 2012 16:12:31 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: a question about efficiency
Message-Id: <4f47a8dd$0$1384$4fafbaef@reader1.news.tin.it>

On 2/24/2012 4:15, Shmuel (Seymour J.) Metz wrote:
> In<4f46a454$0$1388$4fafbaef@reader2.news.tin.it>, on 02/23/2012
>     at 09:40 PM, Kiuhnm<kiuhnm03.4t.yahoo.it>  said:
>
>> Indeed, I've just found out that I can't use wildcards in
>> command-line  arguments because Perl expects the shell to expand
>> them, whereas Windows expects *the program* to expand them.
>
> That's an oversimplification. There's nothing in Perl that prevents an
> argument from containing wild cards, it's possible to escape wildcards
> in the *ix shells and there are other systems besides windoze where
> the shell doesn't interpret wildcard characters. See, e.g., glob EXPR
> in perlfunc.

I'll rephrase it. I can't simply use "while (<>)" like in *ix.

Kiuhnm


------------------------------

Date: Fri, 24 Feb 2012 09:55:46 -0800 (PST)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: a question about efficiency
Message-Id: <7910da45-2b0d-4584-b28e-fab72cb35229@gr6g2000vbb.googlegroups.com>

On Feb 23, 2:36=A0pm, Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:
> On 2/23/2012 2:08, Ben Morrow wrote:
>
> > Quoth Kiuhnm<kiuhnm03.4t.yahoo.it>:
> [...]
> >> Just a question. When I run the following code I get different values:
> >> =A0 =A0 my $x; =A0 =A0 =A0 =A0 # global variable
>
> > This isn't a true global, of course, but a file-scoped lexical. True
> > package globals (declared with 'our' or 'use vars') are never closed
> > over, since they are directly accessible from everywhere.
>
> Now I understand why we write "my" and not something like "var".
>
>
>
>
>
>
>
>
>
> >> =A0 =A0 say for map { sub { $x } } 1..10000;
> >> It seems that Perl uses closures even when there's no real need for
> >> them. Or am I missing something?
>
> > No, you're not. For efficiency reasons, perl doesn't entirely
> > distinguish between this case
>
> > =A0 =A0 =A0my $x;
> > =A0 =A0 =A0for (1..2) {
> > =A0 =A0 =A0 =A0 =A0sub { $x }
> > =A0 =A0 =A0}
>
> > and this case
>
> > =A0 =A0 =A0for (1..2) {
> > =A0 =A0 =A0 =A0 =A0my $x;
> > =A0 =A0 =A0 =A0 =A0sub { $x }
> > =A0 =A0 =A0}
>
> > so it has to create a full closure in both cases. In principle it could
> > work out that in the first case $x is in a section of code that will
> > only run once, and treat it as a global, but that information isn't
> > available at the point where it decides which form of anon sub it needs=
 .
>
> Then we should probably take "sub { $x }" out of the loop (in real-world
> programs, I mean).
>
> > (Incidentally, this issue came up here just the other day in the contex=
t
> > of 'variable will not stay shared' warnings, which are of course very
> > closely related. In that situation perl treats the second case as thoug=
h
> > it were the first, rather than the other way around.)
>
> I'm a little lost here.
> Every closure captures the same instance of $x in the first case.
> If I write
> =A0 =A0say &$_ for map { my $x; sub { ++$x } } (1..10)
> and
> =A0 =A0my $x;
> =A0 =A0say &$_ for map { sub { ++$x } } (1..10)
> I expect to get different results.
> But I probably miss some context here.
>
> Kiuhnm

I think it's documented somewhere that
'my' has both compile-time and run-time
effects. In your former case, it's still
a closure but the run-time resets $x  because of  the scope introduced
by
map; whereas, in the latter, there's no
inner scope to wipe out the incrementing.
Here's an illustration:

perl -E 'my $y; &$_ for map { sub {my $x;++$x;++$y;say "$x|$y" } }
(1..10) '
1|1
1|2
1|3
1|4
1|5
1|6
1|7
1|8
1|9
1|10

Of course, there's probably more to this :)

--
Charles DeRykus


------------------------------

Date: Fri, 24 Feb 2012 21:21:56 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: a question about efficiency
Message-Id: <4f47f163$0$1387$4fafbaef@reader2.news.tin.it>

On 2/24/2012 18:55, C.DeRykus wrote:
> On Feb 23, 2:36 pm, Kiuhnm<kiuhnm03.4t.yahoo.it>  wrote:
>> On 2/23/2012 2:08, Ben Morrow wrote:
>>
>>> Quoth Kiuhnm<kiuhnm03.4t.yahoo.it>:
>> [...]
>>>> Just a question. When I run the following code I get different values:
>>>>      my $x;         # global variable
>>
>>> This isn't a true global, of course, but a file-scoped lexical. True
>>> package globals (declared with 'our' or 'use vars') are never closed
>>> over, since they are directly accessible from everywhere.
>>
>> Now I understand why we write "my" and not something like "var".
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>>>      say for map { sub { $x } } 1..10000;
>>>> It seems that Perl uses closures even when there's no real need for
>>>> them. Or am I missing something?
>>
>>> No, you're not. For efficiency reasons, perl doesn't entirely
>>> distinguish between this case
>>
>>>       my $x;
>>>       for (1..2) {
>>>           sub { $x }
>>>       }
>>
>>> and this case
>>
>>>       for (1..2) {
>>>           my $x;
>>>           sub { $x }
>>>       }
>>
>>> so it has to create a full closure in both cases. In principle it could
>>> work out that in the first case $x is in a section of code that will
>>> only run once, and treat it as a global, but that information isn't
>>> available at the point where it decides which form of anon sub it needs.
>>
>> Then we should probably take "sub { $x }" out of the loop (in real-world
>> programs, I mean).
>>
>>> (Incidentally, this issue came up here just the other day in the context
>>> of 'variable will not stay shared' warnings, which are of course very
>>> closely related. In that situation perl treats the second case as though
>>> it were the first, rather than the other way around.)
>>
>> I'm a little lost here.
>> Every closure captures the same instance of $x in the first case.
>> If I write
>>     say&$_ for map { my $x; sub { ++$x } } (1..10)
>> and
>>     my $x;
>>     say&$_ for map { sub { ++$x } } (1..10)
>> I expect to get different results.
>> But I probably miss some context here.
>>
>> Kiuhnm
>
> I think it's documented somewhere that
> 'my' has both compile-time and run-time
> effects. In your former case, it's still
> a closure but the run-time resets $x  because of  the scope introduced
> by
> map; whereas, in the latter, there's no
> inner scope to wipe out the incrementing.
> Here's an illustration:
>
> perl -E 'my $y;&$_ for map { sub {my $x;++$x;++$y;say "$x|$y" } }
> (1..10) '
> 1|1
> 1|2
> 1|3
> 1|4
> 1|5
> 1|6
> 1|7
> 1|8
> 1|9
> 1|10
>
> Of course, there's probably more to this :)

Yes, I believe there is! Look at the references:

perl -E 'my $y; &$_ for map { sub {my $x;++$x;++$y;say "$x|$y, refs:", 
\$x, "|", \$y } } (1..10) '

As you can see, there are many $x. The label is the same, but they're 
different variables.

Kiuhnm


------------------------------

Date: Thu, 23 Feb 2012 23:22:24 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: Constructing a value beforehand
Message-Id: <4f471080$3$fuzhry+tra$mr2ice@news.patriot.net>

In <871uplpf08.fsf@sapphire.mobileactivedefense.com>, on 02/23/2012
   at 06:43 PM, Rainer Weikusat <rweikusat@mssgmbh.com> said:

>That's an idea someone tried to introduce into 'software design' some
>thirty years ago as 'functional decomposition'

FSVO 30. It's older than that.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org



------------------------------

Date: Fri, 24 Feb 2012 12:50:52 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: tree to array of arrays
Message-Id: <4f47799c$0$1384$4fafbaef@reader1.news.tin.it>

On 2/23/2012 19:43, George Mpouras wrote:
> I want to build an array of arrays from a random tree data structure.
> for example if d... means "directory" and f... "file"
> then from the data
>
> /d1/d7/d8
> /d1/d2/f1
> /d1/d2/f2
> /f1
> /f2
> /d1/f1
> /d2/f3
> /d4/d6/f1

I can't give you Perl code because I still don't know about references 
and how to nest hashes, etc..., but you could just build a tree made of 
hashes and walk it.
You start with an empty tree, e.g.
   my %root;
then you parse your input:
   "/d1/d7/d8"
Let's say "cur" points to %root.
You search for "d1" in cur. If it doesn't exist, you create an empty 
hash with that name in %cur (you store a reference to it, I guess). Now 
you make "cur" reference the hash you've just found or created, and you 
deal with "d7" the same way (but with the new "cur"). And so on...
You'll end up with a tree made of hashes.
Ideally (I don't know about Perl) you should be able to reach "f1" by 
simply typing
   $root{d1}{d2}{f1}      # it's an empty hash, in your example
As an optimization, don't use hashes for simple files (such as "f1", for 
instance).

Then it should be easy to create the array you need.

Kiuhnm


------------------------------

Date: Fri, 24 Feb 2012 16:01:38 +0200
From: "George Mpouras" <nospam.gravitalsun@hotmail.com.nospam>
Subject: Re: tree to array of arrays
Message-Id: <ji855d$1h43$1@news.ntua.gr>

With hashes of hashes is straight forward, but it have to be array, thanks 
Kiuhnm.




------------------------------

Date: Fri, 24 Feb 2012 14:53:25 +0000 (UTC)
From: Willem <willem@toad.stack.nl>
Subject: Re: tree to array of arrays
Message-Id: <slrnjkf935.1aa.willem@toad.stack.nl>

George Mpouras wrote:
) I want to build an array of arrays from a random tree data structure.
) for example if d... means "directory" and f... "file"
) then from the data
)
) /d1/d7/d8
) /d1/d2/f1
) /d1/d2/f2
) /f1
) /f2
) /d1/f1
) /d2/f3
) /d4/d6/f1

If you sort this, it will be much easier.  Is the order important?


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT


------------------------------

Date: Fri, 24 Feb 2012 15:42:56 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: tree to array of arrays
Message-Id: <g8kk19-kht.ln1@news.rtij.nl>

On Fri, 24 Feb 2012 16:01:38 +0200, George Mpouras wrote:

> With hashes of hashes is straight forward, but it have to be array,
> thanks Kiuhnm.

Converting a HaH to a LoL is also rather trivial.

HTH,
M4


------------------------------

Date: Fri, 24 Feb 2012 16:21:33 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: tree to array of arrays
Message-Id: <4f47aafc$0$1381$4fafbaef@reader1.news.tin.it>

On 2/24/2012 15:01, George Mpouras wrote:
> With hashes of hashes is straight forward, but it have to be array, thanks.

As I told you, it's easy to create your array once you have the tree.
You may also decide to create the array directly. The only difference is 
that finding your keys will take linear time.

Kiuhnm


------------------------------

Date: Fri, 24 Feb 2012 17:26:23 +0200
From: "George Mpouras" <nospam.gravitalsun@hotmail.com.nospam>
Subject: Re: tree to array of arrays
Message-Id: <ji8a42$2apo$1@news.ntua.gr>

Yes and no, (for one pass order is important)
But if there is no other way, a initial sort is ok 




------------------------------

Date: Fri, 24 Feb 2012 17:28:46 +0200
From: "George Mpouras" <nospam.gravitalsun@hotmail.com.nospam>
Subject: Re: tree to array of arrays
Message-Id: <ji8a8h$2bg6$1@news.ntua.gr>

for me a random %treehash to $nested_array_of_arrays  is not trivial at all 




------------------------------

Date: Fri, 24 Feb 2012 16:17:46 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: tree to array of arrays
Message-Id: <aqpk19-9e52.ln1@anubis.morrow.me.uk>


Quoth "George Mpouras" <nospam.gravitalsun.antispam@hotmail.com.nospam>:
> I want to build an array of arrays from a random tree data structure.
> for example if d... means "directory" and f... "file"
> then from the data
> 
> /d1/d7/d8
> /d1/d2/f1
> /d1/d2/f2
> /f1
> /f2
> /d1/f1
> /d2/f3
> /d4/d6/f1
> 
> The following array must be created. Any idea is wellcome.

Start like this:

    my $t;
    for (@strings) {
        my $i = $t;
        $i->{$_} ||= {} for split m!/!;
    }

which gives you this structure

    {
        d1 => {
            d7 => {
                d8 => {},
            },
            d2 => {
                f1 => {},
                f2 => {},
            },
            f3 => {},
        },
        ...
    }

Then you can walk that tree converting it into arrays.

Ben



------------------------------

Date: Fri, 24 Feb 2012 18:01:55 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: tree to array of arrays
Message-Id: <87mx88rtyk.fsf@sapphire.mobileactivedefense.com>

"George Mpouras" <nospam.gravitalsun@hotmail.com.nospam> writes:
> for me a random %treehash to $nested_array_of_arrays  is not trivial
> at all

A possible way to do this:

----------------
my %h = (
	 a => 1,
	 b => {
	       c => 1,
	       u => 1,
	       d => {
		     e => 1},
	       f => 1 },
	);

sub to_a($)
{
    my (@a, $v);

    for (keys(%{$_[0]})) {
	$v = $_[0]->{$_};
	push(@a, ref($v) ? [$_, to_a($v)] :$_);
    }

    return \@a;
}

use Data::Dumper;

print Dumper(to_a(\%h));
------------------


------------------------------

Date: Fri, 24 Feb 2012 20:35:32 +0200
From: "ntua" <nospam.gravitalsun@hotmail.com.nospam>
Subject: Re: tree to array of arrays
Message-Id: <ji8l9n$139u$1@news.ntua.gr>

that is excellent, thanks alot Rainer. I think now I can make the whole 
think work.
first tree -> hash   and then your solution 



------------------------------

Date: Fri, 24 Feb 2012 20:44:23 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: tree to array of arrays
Message-Id: <4f47e896$0$1387$4fafbaef@reader2.news.tin.it>

On 2/24/2012 19:35, ntua wrote:
> that is excellent, thanks alot Rainer. I think now I can make the whole
> think work.
> first tree -> hash and then your solution

Just keep in mind that hashes don't care about order. If order is 
important to you, you'll need a tree of "pairs", i.e.
   nameDir => (position, hash).
When you create a *new* hash (or, better, pair), its position will be 
the current number of siblings (initially 0). Now, when you create the 
arrays, you will use "position" as an index, instead of just pushing the 
value.

Kiuhnm


------------------------------

Date: Fri, 24 Feb 2012 20:47:04 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: tree to array of arrays
Message-Id: <ji8t08$2s3$1@reader1.panix.com>

In article <4f47e896$0$1387$4fafbaef@reader2.news.tin.it>,
Kiuhnm  <kiuhnm03.4t.yahoo.it> wrote:
>Just keep in mind that hashes don't care about order. If order is 
>important to you, you'll need a tree of "pairs",

or use Tie::Hash::Indexed or Tie::IxHash, which appear to have a hash
interface yet care about order.

-- 
Tim McDaniel, tmcd@panix.com


------------------------------

Date: Fri, 24 Feb 2012 23:00:55 +0200
From: "George Mpouras" <nospam.gravitalsun.antispam@hotmail.com.nospam>
Subject: Re: tree to array of arrays
Message-Id: <ji8tq8$26m8$1@news.ntua.gr>

tie is also slow compared to direct assignments


------------------------------

Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>


Administrivia:

To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.

Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests. 

#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.


------------------------------
End of Perl-Users Digest V11 Issue 3622
***************************************


home help back first fref pref prev next nref lref last post