lua-users home
lua-l archive

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

2012/2/1 Miles Bader <>:
> No I'm not going to put any effort into countering your whine.

Thank you Miles. I see that often when I want to discuss something in
the ML my emails are labeled as whining. Probably I will stop soon or
later to discuss whatsoever in this mailing list.

Otherwise you didn't bother to give any link about Mike's approval for
the goto stuff. May be it was in a private communication or is a
conference speak ?

> Yeah, we all know about Dijkstra.  He was speaking in another time, when
> goto was widely abused.  His hyperbole served its purpose, but today is
> a different world, and idea of "goto" as some sort of unspeakable evil
> whose use is never justified is naive.

Yes today is a different world but the reasons that where good in past
are still good today. Spaghetti Lua code with many gotos will soon
appears in many libraries and applications as more and more unskilled
programmers will begin to work with Lua 5.2.

In my point of view there were a few points were Lua was lacking some
appropriate control structure. These are:

  - the else statement in "for" loop present in python
    => cannot be implemented natively in Lua without an addition boolean
  - the lack of "continue" statement
  - generated code for state-based machine
  - cleanup/resource disposing in case of error inside a function

IMHO the introduction of "goto" give an answer to these points but in
the long term in can make more harm that the benefits it introduces.

The "else" statement for "for" loop was the good answer for the first point.

The introduction of the "continue" statement was enough for the second
point. For me it is very odd how the same arguments that prevented the
introduction of the continue statement have been ignored when
introducing the goto statement. Here an illustration. The following
code snippet is invalid:

  for i = 1, 10 do
    local x = 2*i
    if i < 5 then goto a end
    local y = i + 1
    print(x, y)

while the following is valid:

  for i = 1, 10 do
    local x = 2*i
    if i < 5 then goto a end
    local y = i + 1

but both violates the rule that a goto cannot jump in a scope where a
new local was defined. This was exactly the same reason that prevented
the introduction of the continue statement and for the goto:

  - the same reason was just ignored => you can do with goto the same thing
    that "continue" does
  - the Lua rule about valid/invalid goto is illogical

In addition prepare to a lot of headaches by reading Lua code full of
gotos, good luck.

Talking about the other two points (state machine and resource cleanup
on errors), well, goto is definitely useful but Lua main goal
shouldn't be to be a target language for code generation and code
cleanup can be done without gotos even if it is slightly less elegant.
And once again, in my point of view, the problems introduced with
gotos outweight the benefits it does introduce.

And please stop saying that I'm whining, I'm discussing and I give
arguments about my points!