 |
lua-l archive |
|
|
||
|
I acknowledge it's not perfect, but it does have precedent in theOn Thu, Jul 31, 2014 at 2:09 PM, Andrew Starks <andrew.starks@trms.com> wrote:
>
>
>
> On Thu, Jul 31, 2014 at 3:56 PM, Coda Highland <chighland@gmail.com> wrote:
>>
>> On Thu, Jul 31, 2014 at 1:48 PM, Andrew Starks <andrew.starks@trms.com>
>> wrote:
>> >
>> >
>> >
>> > On Thu, Jul 31, 2014 at 3:46 PM, Coda Highland <chighland@gmail.com>
>> > wrote:
>> >>
>> >> On Thu, Jul 31, 2014 at 1:39 PM, Dirk Laurie <dirk.laurie@gmail.com>
>> >> wrote:
>> >> > ---
>> >> > table.copy (a1, f, e, [a2,] t)
>> >> >
>> >> > Copies elements from table a1 to table a2. This function performs the
>> >> > equivalent to the following multiple assignment: a2[t],··· =
>> >> > a1[f],···,a1[e]. The default for a2 is a1. The destination range can
>> >> > overlap with the source range. Index f must be positive.
>> >> > ---
>> >> >
>> >> > I have mixed feelings about this. Last year [1] John Hind and I
>> >> > wrote a module called "xtable" containing a function block.move
>> >> > such that when e>=f,
>> >> > block.move(a1,f,e,t)
>> >> > does exactly what the above definition of
>> >> > table.copy(a1,f,e,t)
>> >> > does. So I should be very pleased. However, I am not delighted
>> >> > by an optional argument preceding a non-optional one. It violates
>> >> > my sense of conceptual integrity.
>> >> >
>> >> > [1] <http://lua-users.org/lists/lua-l/2013-04/msg00016.html>
>> >> >
>> >>
>> >> You know, maybe the resolution is to define separate move() and copy()
>> >> functions, where move() doesn't accept a destination, and copy()
>> >> requires one.
>> >>
>> >> /s/ Adam
>> >>
>> >
>> > But my read of the documentation tells me that the original values
>> > remain.
>> > Is that not the case? If it is, then move is more confusing, to me.
>> >
>> > -Andrew
>>
>> If the destination range overlaps the source range, you'll see why
>> it's a "move" operation.
>>
>> /s/ Adam
>>
>
> yes, but I didn't read that the non-overlapping values will be removed.
> Assuming that a2 is absent:
>
>
> a1[2], a1[3], a1[4] = a1[1], a1[2], a1[3]
>
> I believe that a1[1] is still present, no? If it is, do you still think
> "move" is more appropriate?
>
>
> --Andrew
>
programming world, going way, way back -- x86 assembly language, for
example, calls a register-to-register copy "MOV", and the operation
mimicks the POSIX memmove() function.
/s/ Adam