lua-users home
lua-l archive

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


On Mar 19, 2013, at 7:29 PM, Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br> wrote:

>> I'm talking about ALL attempted accesses of undefined variables, including table/array/class elements. I was wondering if addressing this in a major version update of the language has been considered before and if there are reasons for retaining the current behavior.
> 
> Lua's take on this is that undefined variables contain nil. That's the
> purpose of nil. That's by design, from day one. On the other hand, Lua
> provides mechanisms for handling this differently if you wish. It has
> done so from day two.
> 
> Perhaps you only need getting used to it. After a while, it feels right.
> Just try it.
> 
> We've all been there before and I now rarely have an undefined variable
> bug that is not caught as soon as possible because nil cannot do anything
> useful.

I've worked with Lua for a number of years, and I'm sorry to say it feels unsafe because of my experience with it. You end with the point that we have all been there, which is also the point I'm making. It's a bug caused by fast typing, and we've all been there and will continue to be. I've had the opportunity to work with other embedded languages that do raise an error for this, and it's surprising how often it still happens among a team of professional programmers. Google's Street View team created http://code.google.com/p/lua-checker/ for this issue because "[i]n practice, Lua programs over (say) 1000 lines tend to accumulate these kinds of problems, making debugging difficult."

Despite anticipating some resistance on this topic, and with well-earned respect aimed at Lua's curators, I felt it important to make a case because of these experiences.

Preston