lua-users home
lua-l archive

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

On 11/19/2017 3:31 AM, Paige DePol wrote:
KHMan <> wrote:

Let me just state for the record that I have no objection to the current Lua 5.3.x behaviour. Corner cases have to be handled; there are no beautiful solutions. So they are handled, but is it a good idea to start habitually relying on corner cases?

I would just steer well and truly clear of all things slippery. No fractions in loops. No mixed numbers. No out of range numbers. No numbers close to data type limits. Just loops with zero surprises.

Considering it was your example code that kicked off this entire discussion
about the problems with loops I would have thought you would appreciate the
patch I crated and would want to see it applied to the codebase.

IMHO it is not wrong for Lua to keep current behaviour. It's 2s complement arithmetic just like such a loop in C. But it would be nice for the ref manual to talk more about what it does with numeric loops. That section is maybe too brief.

Why was I initially surprised by the math.maxinteger limit not working? Because I don't write loops like that in normal code. Why then was I using math.maxinteger? Because PiL4 had this loop idiom using math.huge as the limit, for which the Lua VM substituted math.maxinteger for integer loops. Like this:

for i = 0x7FFFFFFFFFFFFFF8,math.huge do
  if i == -0x7FFFFFFFFFFFFFF0 then return end

But if we don't substitute math.huge with math.maxinteger, then substitute what? There are no perfect answers to that. It will always be some kind of special behaviour. My take is, don't touch that in the first place.

If I thought it was an open-and-shut case I would have called it a bug and offered a patch. But no, perhaps my bias is that I have seen all too many corner cases in my time and have no desire to handle or fix each and every corner case. For example, for automotive firmware, one codes a only subset of what a language is capable of, one does not step on the slippery stuff. It's hardly ideal, yet this is what companies like SpaceX do successfully -- that is, use C++ carefully instead of Ada.

At least with my patch one surprise is removed when using min/max integers,
and another when using floating loops and a step size magnitude that is
too small to properly affect the loop variables. Thinking about what Dirk
said as well, one final tweak could be done with floating loops by adding
half the step size to the loop limit variable to ensure the final iteration
is executed in the case where the floating precision drifts.

I don't have such confidence in float loops. Unless this is in some sort of math algorithm, I would never allow things to go drifting when there is another way of coding things. Therefore I do not see anything that needs to be fixed here.

They say C is a dangerous language, but I guess all languages have corner cases if one goes looking for dangerous things to do. It's the coder's responsibility to write robust code and algorithms.

Granted, these are issues that probably don't come up all that often, but
since the patch is really just a small logic shift it would seem better
to apply it than not. Loops with zero surprises are very nice, especially
if the language helps take care of that and not the developer! ;)

I would leave this to Roberto & co. But I would love to see a bit more detail in the ref manual.

I don't expect Lua to be a benign environment. Build an app with Lua embedded in it, and you make all sorts of function calls, some may be dangerous, some may have unorthodox conventions, etc. So I like myself to apply good coding discipline, rather than burden loops with more and more behaviours.

Kein-Hong Man (esq.)
Selangor, Malaysia