Re: Odd behaviour with multiple return values and varargs

[David Kastrup <dak@...>]

"Tom Miles" <Tom@creative-assembly.co.uk> writes:

>> Huh?  We are not talking about "unexpected values", but "an
>> unexpected number of values" in a hypothetical non-Lua language
>> that then consequently thwarts the list/value relationship.
>> 
>> I am saying that this non-Lua language is not a good idea, and Tom
>> Miles demands that I should write code as if I had to deal with
>> this non-Lua language, and now you call my code "at fault" for not
>> working under this hypothetical non-Lua language?
>> 
>
> Sorry if I've offended you, but I'm not *demanding* anything.  I'm
> also not talking about a hypothetical non-lua language, I'm trying
> to understand a justification for something that I see as counter
> intuitive within the language am I trying to use.
>
>> Why would I know that?  Why should I need to know?
>
> I would have thought if you were calling a function you would want
> to know what it does!

If the syntactical relation of code can't be guessed just from reading
it, that's a bad idea.

>> I am sure we can get even more absurd if we really try, but I 
>> don't think it worth doing.
>> 
>> >> Anyway, there is no reasonably elegant way to rewrite something like
>> >>
>> >> a, i = f(a+1,i), f(i,a)
>> >>
>
> The same argument can be used for what I am trying to do, only I *have*
> to use temporary variables.  What I was trying to do is:
>
> function Position()
> 	return x,y
> end
>
> function Dimensions()
> 	return w,h
> end
>
> function push_clip(x,y,w,h)
> 	-- Do stuff
> end
>
> push_clip(Position(), Dimensions()) 

See how bad the idea is?  Hide away the definition of Position and
Dimensions, and you have _no_ clue whatsoever what arguments can be
affected from "Dimensions".  Worse: a bug in Position will clobber the
relation between w, h, and Dimensions, leading to symptoms in an area
completely unrelated to the actual bug.

-- 
David Kastrup