Bug or just something you can't do ?

[Alex Tweedly]

On 01/10/2012 00:15, Richard Gaskin wrote:
>
> I would have expected it, but I can see value in allowing what you 
> suggest.  I'm just not sure how to go about it.
>
> Args are evaluated before being passed in, so:
>
>    increment tA[1]
>
> ...becomes:
>
>    increment (the value of element "1" in the array tA)
>
?
So doesn't
    increment t
become
   increment (the value of t)

?

If you look closely at the simple case
> command increment @p
>    add 1 to p
> end increment
>
> on mouseUp
>    local t, tA
>    put 2 into t
>    increment t
>    put t &CR after msg
you see that *because the parameter specifies 'pass-by-ref',* a 
reference to the container is passed, without evaluating the actual 
parameter. So what I woudl expect (or at least, wht I want :-) is for
    increment tA[1]
to be evaluated as far as
    increment (the reference to the container tA[1])

> One option for passing the array would be to pass the whole thing with 
> a specifier for the element to be affected as a separate argument:
>
>   increment tA, 1
>
> But you've probably already considered that.
>
Yeah. My problem is that I have a whole set of functions that take in an 
array, passed by ref, and update that array; I've now realized that *in 
some cases* the calling handlers don't need just one (or two) array(s) - 
they need to handle a large number of arrays. So I changed all the code 
from something like

    ("read the data into gArray")
    put myFn(gArray) into tResult

into something like
    repeat for each dataset D
       read data into gArray[D]
       put myFn(gArray[D]) into wherever
    end repeat

But of course, in other places, I still only have a single array to deal 
with.

For now I've inserted the ugly construct

    repeat for each dataset D
       read data into gArray[D]
       put gArray[D] into temparray
       put myFn(temparray) into wherever
       put temparray into Array[D]
end repeat

(ick !! - but it works)

> So we have a question:  if enough folks find this sort of suggested 
> syntax useful, by what syntactic means could we tell the interpreter 
> not to evaluate the argument?

There's no need for any syntactic means - the use of "by-ref" in the 
handler specification is already there, and is already used to 
differentiate how to pass it in the "simple case" (unless I'm missing 
something).

-- Alex.