Re: Integer division

[Wolfgang Pupp <wolfgang.pupp@...>]

Could we not solve this problem (wanting 64bit integers and the
corresponding operators) just the same way LuaJIT did?

Allowing int64- literals ("local v = 5ll or 5ull") and always (!!)
coercing *all* operands (and the result) to integer type would be
enough, and things would stay as clear and intuitive as they are
(integers would only be used when explicitly needed, e.g. to represent
file offsets or handles or just really big ints).

The type function could just return "userdata" or "int64_t" /
"uint64_t" or "cdata"- that way the programmer could track down
integers "poisoning" his calculations (by type coercion) very fast.
This would also allow ints and numbers (of same value) to be different
table keys, without confusing people too much- why would they share
the same key slot if they have different types, after all?

Casting back to the Lua-number type could be done via tonumber (loss
of precision possible).

tostring should return a visibly different result if the argument is
an int and not a number (e.g. 5ULL instead of 5).

Finally, making the bit* library work for such int64 types would be very nice.
I'm against bitwise operators because there are too many of them- too
hard to remember precedence rules for all of them. There are also some
things that *belong* into a bit library IMHO but don't have suitable
operators (popcnt would be very nice, e.g.), so a bit* library is
needed, anyway.

I'm pretty sure that *all* of this would only need minor changes to
the parser *only*- the rest could already be achieved via the Lua-C
API (with userdata as the underlying Lua type for ints).
Everything would be completely compatible with existing Lua code.

Examples:
    = 2ll * 3ull --> 6ULL
    = 5ull * 2.5 --> 10ULL
    = 0ull - 1 --> A LOT

IMHO this should definitely be evaluated before considering more
drastic changes...

--Wolfgang