develooper Front page | | Postings from September 2000

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

Thread Previous
Jeremy Howard
September 8, 2000 15:09
Re: RFC 90 (v3) Arrays: Builtins: merge() and demerge()
Message ID:
Matthew Wickline wrote:

> (not on list, just tossing this in for discussion)
OK--we'll keep you cc'd in on this 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
> 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 = ();

  @merged_list == @b;

> 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.
On assignment to another list, an array copy would have to occur. In this
case the result of this operation is pretty obvious.

> 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).

You're right that there's a lot of bookkeeping, and I'm not sure it's worth
it either. Perl's current slicing operation C<@a[$x1, $x2]> only aliases
when used in an lvalue context:

  @a = (4,5,6);
  @b = @a[1,2];
  @b[0] = 9;       # @a == (4,5,6)
  @a[1,2] = (8,9); # @a == (4,8,9)

We could do the same for merge(). The downside is that:

  @transpose = part(
    # Find the size of each column
    scalar @list_of_lists,
    # Interleave the rows

and similar expressions would do an awful lot of copying. Ideally if merge()
didn't alias in an rvalue context, Perl would still optimise away multiple
merge()s, part()s, slices, and so forth so that only one copy occurred.

> 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. ;)
This was discussed quite a bit when v1 of this RFC was released. It's a
common operation for working with multidimensional arrays, and for efficient
looping through multiple lists, both of which are important in data

If it were in a module, then the elements required to make it's complex
optimization behaviour work would have to be definable in a module. I
haven't seen an RFC that provides such a capability.

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