Make Superfluous Tokens Optional

lua-users home
wiki

Lua requires 'then' following an if statement, and 'do' following while and for statements. These are totally superfluous, and I propose they be made optional. They add unnecessary wear and tear on our tendons and make code harder to read (the eye is better at distinguishing beginnings and ends). Code is cleaner and easier to read without them:

  local n = 10
  if n > 5
    for i=1,n
      local x = n
      while x > i
        x = x - 1
        io.write(x)
      end
      io.write('\n')
    end
  end

It's a trivial change to the Lua code (LuaPowerPatches), increases Lua's performance (insignificantly, but provable), and is 100% backwards compatible.

I find it easier to read with the dos and thens. It scans more easily when you are reading it. It is easier to see where the blocks begin and end, and you know a scope is between a do and end. You don't have to evaluate the expressions to see if they are complete (i.e. because the eol ; is optional). Of course brackets can be added to ensure expressions are complete, but then these are optional and superfluous too. --NDT

I don't find it easier.

First of all, recognizing blocks is hardly difficult in well-written C/Pascal/Lua/..., thanks to indentation. Python goes so far as to use indentation as the sole indicator of block scope. It works.

Truth be told, I find it hard believe that you actually look for 'then' and 'do' keywords to see where blocks begin. My eyes scan the left side of the code to determine block structure, matching up the 'if', 'for' and 'while' statements with their corresponding 'end' statements, purely by indentation. Only if there was a bug, something to make me suspect that the indentation as misleading, would I begin scanning the right side of the code.

Of course, I don't put multiple statements per line. Perhaps if I did, I would be forced to develop the habit of ignoring indentation and scanning for delimiters to figure out the structure of my code. But I prefer to format code consistently, believing that it makes recognition easier.

So, with block structure made transparent by consistent formatting, how else can we aid rapid recognition? By putting important parts of a statement at the beginning and end of a line, where the eye can see them most readily. The same principle applies to choosing good variable names:

  foobar1
  foobar2
  
is better than:
  foo1bar
  foo2bar
  
likewise:
  if a
  if e
  
is better than:
  if a then
  if e then
  
Even if you disagree, and just want to chock it up to a matter of taste, I don't see why it shouldn't be made optional. I doesn't hurt Lua in the slightest. --EricTetz

I don't find lua code easier to read with the "then" token either. Make it optional, there's no legitimate reason not to. --DanHollis?

Agree. And I'd be happy if I could write 'def' instead of 'function' like in Python or Ruby - it is shorter. --YuraSokolov?

I find then clean and readable when having several conditions, e.g.

  if
    (cond1 == val1) and
    (cond2 ~= val2) or
    (cond3 <= val3)
  then
    -- code block
  end
For the sake of consitent syntax I vote for leaving it in. But on the other hand, you could say the same about optional parenthesis --SajberToffe?


Although then was completely redundant in Lua 4, this changed when the grammar was changed to allow call and assignment statements to start with a parenthesized expression; this change made the ; statement terminator only semi-optional. The following could not be written without then because ; can only go after a statement; without the then it would be ambiguous:
  if x then (funcs[x] or default_func)() end

Moreover, do cannot be optional in a for or while statement because the block could itself start with a do statement:

  while x > 100 do
    do 
      local y = f(x)
      g(y)
      h(y)
    end
    -- ...
  end

The above code limits the lifetime of y which might be useful if it were a large object and the remainder of the while loop was quite time-consuming.

If do cannot be optional, then the only unambiguous possibilities are required or forbidden; if it is forbidden, then the ambiguity noted above in the if statement is unresolvable.

C gets around the ambiguity of following the conditional expression with a statement by requiring that the conditional be surrounded by ( ) and it uses { and } instead of do/then and end; it also requires that statements be terminated with ;. In the end, it's pretty well a much of a muchness -- the relative appeal will depend on whether you prefer punctuation to English words or not.


RecentChanges · preferences
edit · history
Last edited December 24, 2005 6:58 am GMT (diff)