lua-users home
lua-l archive

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

On 4/13/07, Olivier Galibert <> wrote:
On Fri, Apr 13, 2007 at 03:27:17PM +0200, Olivier Delannoy wrote:
> Lua should not evolve in a way that makes the language more complex
> and not clear for the sake of not writing a few more extra characters.
> Lua is small and should stay small. 1 more vote against += -= *= /= --
> ++ and all other operator added to the language for programmer
> lazyness. If one want all this operation its another language and it
> can go with one providing this kind of facility.

Oh please.  Read the thread you're replying to, if += and ++ were
*only* syntaxic sugar it wouldn't be a problem to add them.  It's
because they imply way more than that that there are issues.

In what i++ is different from i = i + 1 (I assume post increment here.)

For those who stumble on this post, some of the real reasons are:
- in lua assignation is a statement, not an expression, and people who
  want ++/-- want to use it as an expression.  Assignation-as-expression
  carries a lot of complexity for the programmer/maintainer a
  non-professional-programmer language lika lua would rather avoid.

- lua's multi-assignation does not interact very well with += and friends

- all these operators have in-place modification and atomicity semantics
  that do not go very well with lua either.  ':' is already more complex
  in that area than one would think at first glance.

Could you details the in-place modification in the context of the lua
stack and state please ?

Atomicity as no meaning in lua. Lua is not multi threaded and there is
only one execution thread per state active at a time. so a whool chunk
can fairly well be considered atomic.

Why : is more complex than it appears ?
a.truc(a, something) is strictly equivalent to a:truc(something)

As usual, power and complexity go hand in hand, and in that case the
complexity rise is too high.


Olivier Delannoy
PRiSM Laboratory
Versailles University, FRANCE