lua-users home
lua-l archive

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


Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br> wrote:

>> In the history of Lua has the language ever been completely re-written
>> from scratch, or has it always just built upon previous versions?
> 
> Always just built upon previous versions. The code was reorganized in
> Lua 3.1 and the parser was rewritten from scratch to avoid yacc.
> 
> The code for all versions is conveniently available in the lua-all package:
> 	http://www.lua.org/ftp/lua-all.tar.gz

I downloaded that tarball and took a peek, Luiz. Wow, it really has just
organically grown straight from v1.0 onward. There is code in those older
versions that is still in Lua today, that was quite interesting to see.

I noticed in the original Lua code that the code formatting is quite a bit
different than the Lua code of today... including single-space indents! Was
there a reason for using a single space vs two or more, or tabs? I only ask
as I almost never see single space indents in source code so was curious if
it was done for some specific reason.

I am going to guess it was probably just personal style as at some point
it seems Lua migrated to two spaces (with a couple exceptions). I am not
trying to say the style is wrong or anything like that, I just wondered
if there was a specific reason for the decision is all.

For example, the Linux kernel developers mandate 80 columns with *8* spaces
per tab for two reasons; to make visually projecting the source code on a
screen easier to read, and to prevent newer kernel developers from writing
"bad code" by creating too many lexical blocks.

Thanks again for pointing out that tarball, it was fun to look at the
development history of Lua. I suppose one good way to become familiar with
the Lua codebase would be to start at v1.0 and work your way up by reading
the diffs to the current version... though I suppose then you would wind
up having to learn and then unlearn things that were changed over the years.

From a code refactoring point of view, is there still a need to limit code
to 80 columns? When I code in ObjC I always use 132 columns, but then ObjC
tends to be quite the verbose language. I know screen projection during
conferences is probably one of the main reasons to stick to 80 columns.

~Paige