lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

"Tom Miles" <> 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