Re: duplicated local variables with same name

[Rena <hyperhacker@...>]

On Wed, Jun 17, 2015 at 5:21 PM, Robert Virding <rvirding@gmail.com> wrote:
> When I first implement luerl, Lua in erlang, I didn't realise this and just
> overwrote the variables. But eventually I read the manual a bit more closely
> and got it right. I find personally find it both logical and illogical,
> coming from other languages I would expect the compiler to complain.
>
> Robert
>
>
> On 16 June 2015 at 23:24, Brigham Toskin <brighamtoskin@gmail.com> wrote:
>>
>> On Tue, Jun 16, 2015 at 1:53 PM, Soni L. <fakedme@gmail.com> wrote:
>>>
>>> On 16/06/15 05:42 PM, Brigham Toskin wrote:
>>>
>>> I'm curious if you've actually dumped the traces to see this difference,
>>> or if you're assuming it will do this based on documentation or some other
>>> thread on the subject?
>>>
>>> I'm assuming based on documentation/other thread, and also this: the
>>> opcodes indicate "local x do x = function() end end" loads "nil" into x,
>>> then changes x later, so LuaJIT can't just assume "x" is constant/immutable
>>> so instead it uses an indirect jump when you call x. with "local x =
>>> (function(...) return function() end end)(...)" there's a call opcode but x
>>> doesn't get implicitly nil-ed before it.
>>
>>
>> This seems like exactly the kind of situation the tracing compiler might
>> excel at optimizing "properly". Though that argument's moot if in fact it
>> doesn't. Might be worth checking out, for those people that use blocks like
>> this a lot.
>>
>> --
>> Brigham Toskin
>
>

It has bit me a few times:

local min, max = math.min, math.max
[...]
function frobulate(obj)
    local size, rate, max = obj.size, obj.rate, obj.max
    [...]
    x = max(size, config.min_size)
end

-- 
Sent from my Game Boy.