lua-users home
lua-l archive

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



Jim Mellander wrote:
My 2nd favorite language (awk as implemented in gawk), which also uses a
double as the numeric type, takes the following tack when doing bitwise ops:

"For all of these functions, first the double-precision floating-point
value is converted to the widest C unsigned integer type, then the
bitwise operation is performed. If the result cannot be represented
exactly as a C double, leading nonzero bits are removed one by one until
it can be represented exactly. The result is then converted back into a
C double. (If you don't understand this paragraph, don't worry about it.)"

from http://www.gnu.org/manual/gawk/html_node/Bitwise-Functions.html
That would be the behavior I'd expect from a bitwise-aware-Lua.
Philippe Lhoste <PhiLho@GMX.net>

Why?

Indeed, they are useful to combine flags (DS_MODALFRAME | DS_3DLOOK | DS_FIXEDSYS | WS_POPUP | WS_CAPTION | WS_SYSMENU) but also to get R, G, B, A components out of a RGBA number and to parse some binary file formats, for small bit maps, and so on.
This brings up 2 good points. (Please keep in mind I'm writing from a game dev PoV.)

1 - Enumerations:

Enumerations are something that could be either done in Lua, or in the VM (Faster/Prettier).

Lua example:

-- More on this typecheck thing in another message I'll send after this, though you should be able to guess easily what I mean
local function typecheck(varUnknown, strTypeName)
   <snip snip, check the type to insure it matches the expected type>
<if not matching then an error /w require 'C-Lua' styled message else just bail out>
end

local HackEnumCntr = 0 -- Hack enumeration incremental counter

function enum(strEnumSetName, tblEnumList)
   typecheck(strEnumSetName, "string")
   typecheck(tblEnumList, "table")
for k, v in ipairs(tblEnumList) do
       HackEnumCntr = HackEnumCntr + 1
_G[k] = 2^HackEnumCntr -- Figure something for handling over overflows?
       -- Is it even a possible concern? Never was in my experience...
   end
end

enum("Test", {"Div", "Multi", "Add", "Sub", "Exp", "Assign", "Call"}) -- Create the set

Note that it's not permitted to do:

enum "Test"
{
   "Div",
   "Multi",
   "Add",
   "Sub",
   "Assign",
   "Call"
}

And most certainly not (unless you added some clever metatables to the env table and recorded the order & keys):

enum Test
{
   Div,
   Multi,
   Add,
   Sub,
   Assign,
   Call
}

As for an example in the VM, that's a bit too involved an implementation to do just for a discussion, though it would make sense to put them where high speed access is possible (registry? might cause problems...) and give them incremental powers of two. This could be reset to zero for each new set (safer, less likely to overflow if you have a ridiculous number of them), or kept global (more susceptible to overflows, but all enums are unique, even from other sets).

I'm not sure this is a good idea to make this a vanilla Lua VM feature, because that would involve a new keyword. (And if I had a choice between adding an enum keyword and a continue keyword, I'd pick continue!)


2 - Bitwise Ops:

As Philippe was so kind to point out, though flags using bitwise-or-ing is a nice feature, it would be more beneficial to have full bitwise ops for numbers. Data processing directly in Lua of what is usually manipulated only by C/compiled languages is of interest to quite a few people I'd believe, myself included. Jim have an account of how (g)awk handles bitwise ops which was basically what I'd envisioned for Lua bitwise ops.


Important Note - Avoiding the Swiss Army Chainsaw:

That said, the Lua authors do have an (very) valid interest in keeping Lua from becoming another chainsaw (or so this is the reason I gather behind being careful of adding things on a whim).

Enumerations/Flags are two things that could be kept from vanilla Lua, since I don't know how important such a feature would be to other users of the language and it it's a rather 'loud' thing to add, since:
1. It's a syntax similar to table construction
2. It introduces another (pseudo?) structure-ish entity to the language
3. It doesn't benefit the language as a whole, it's more a (multiple-?)domain specific feature

However bitwise ops are important to mos people (everyone?) who do any sort of in-depth data-comm/handling with C/compiled languages, since it allows us to implement/develop/prototype algorithm in Lua. It also allows us to handle C data more effectively as well (Philippe's bitmaps, for example, and binary formats too). Although it could be done with bitlib (Lua-side), I don't think Philippe (or myself) would be happy manipulating tiny datums with lots of table ops (if you loop at bitlib it uses a lot of tables behind the scene, but it does produce correct results, it's not very nice when you're trying to keep GC cycles to a minimum too).

Olivier