(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. ;) -mattThread Previous | Thread Next