develooper Front page | | Postings from September 2000

Re: RFC 90 (v3) Arrays: Builtins: merge() and demerge()

Thread Previous | Thread Next
Matthew Wickline
September 8, 2000 12:41
Re: RFC 90 (v3) Arrays: Builtins: merge() and demerge()
Message ID:
(not on list, just tossing this in for discussion)

RFC 90 (v3) wrote:
-> Both C<merge> and <demerge> do not make
-> a copy of the elements of their arguments;
-> they simply create an alias to them:
1>   @a = (1,3,5);
2>   @b = (2,4,6);
3>   @merged_list = merge(@a,@b);   # (1,2,3,4,5,6)
4>   $merged_list[1] = 0;
5>   @b == (0,4,6);                 # True

Hmmmm.... This seems rather expensive, and like it might be
cheaper to just create a new list rather than dealing with the
aliasing thing.

In order for the aliasing thing to work, perl would have to keep
track of all these aliases through a large number of possible
operations. Suppose that in the above code, after line 3 I
decided to to say
    @a = ();
Now @merged_list must be seriously adjusted as well. What if I did
    @a = (@merged_list, @b, @a, reverse @merged_list);
Not only is that likely to be a great deal of work, but I can't
even begin to think about what the result should be. I don't
think that it can be defined.

The problem in that case is that you've got a recursive
definition with no base case.

So, I would say that an easy solution is to return a non-aliased
list. If you need the aliasing effect, then you need a way to
avoid recursion problems (and you probably just have to bite the
bullet with respect to all the extra bookkeeping work perl would
have to do). I'd want to stuff it in a module, but then I'd want
to do the same with any other core feature I don't use much, so
that opinion ain't really worth all that much. ;)


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About