Lua rants, because we all love it!

local t = {
  print = function(self) print(self.text) end,
  text = "quix"
}
local mt = {
  __index = function(t , k)
	if type(rawget(t, k)) == "function" then
	  return function(...) rawget(t, k)(t, ...) end
	end
	return rawget(t, k)
  end
}
setmetatable(t, mt)

t.print()

local t = {
  print = function(self) print(self.text) end,
  text = "quix"
}

local _t = t
t = {}

local mt = {
  __index = function(t, k)
	if type(_t[k]) == "function" then
	  return function(...)
		_t[k](_foo, ...)
	  end
	end
	return _t[k]
  end
})

setmetatable(t, mt)

t.print()

"Hello " + "World"

"Hello " .. "World"

lucy-san, on 11 January 2015 - 03:18 PM said:

So yeah, I've been doing some metatables lately and felt like ranting a bit.

__index: What the actual f, lua devs? A bloody function which name indicates that it is run every time a field in table is indexed, but no no no! That would be too easy to use, wouldn't it? So instead of doing a normal index handler let's do one that is called whenever indexed field is nonexistent! Great idea! So instead of doing

lucy-san, on 11 January 2015 - 03:18 PM said:

local: Oh yes, local variables. This keyword shouldn't exist. Because there should be no need for it's existence! Every goddamn variable should be local by default! And if You need global variable (what happens never very rarely with proper design) you cloud use for example a "global" keyword, uh?

Lignum, on 11 January 2015 - 03:47 PM said:

String concatenation. When I first used Lua, I tried to do this:

"Hello " + "World"

But no, that's too complex for such a lightweight language. We have to do this:

"Hello " .. "World"

"1" + "1" -- 2

Spoiler

SquidDev, on 11 January 2015 - 05:39 PM said:

In any normal language I would agree, but some languages (Lua, VB, I'm sure there are others - maybe ActionScript and PHP) have type conversion things. This is the trouble:

"1" + "1" -- 2

But I wanted 11! These are strings, but we get a number out of it? Explicitly defining addition or concatenation is really the only solution.

SquidDev, on 11 January 2015 - 05:39 PM said:

Anyway, it isn't as bad as some languages:

Spoiler

SquidDev, on 11 January 2015 - 05:39 PM said:

Sorry for the long post.

lucy-san, on 11 January 2015 - 05:47 PM said:

Well, unless javascript it shouldn't be a problem ;)/>
>only solution
Uhmm, for example: don't store ints as strings? :D/>

lucy-san, on 11 January 2015 - 05:47 PM said:

It would be a rather hard thing to be worse than a fractal of bad design :D/>
We are actually going to cast some of these fine sidehammers from aluminum in local Hackerspace :D/>

lucy-san, on 11 January 2015 - 06:58 PM said:

>The thing is Lua works.
PHP works as well.
AFAIK lua was never meant to be a professional language, but a simple language for modding, etc. It gets job done, but it could get job done in nicer way. No language is perfect and lua is not bad, neither is excellent rough.

SquidDev, on 11 January 2015 - 06:03 PM said:

I would suggest looking at ElvishJerricco's LuaLua. He has managed to get Yueliang working in CC. See if you can use it to make fix concatenation and locals!

function concat(s1, s2)
    return s1 + s2
end

lucy-san, on 11 January 2015 - 06:58 PM said:

Maybe, but it would be pointless - it's like lua compiled to JavaScript, but worse. Running lua in lua in Java VM will not be an efficient solution ;)/>

Bomb Bloke, on 11 January 2015 - 10:40 PM said:

Removing "local" altogether would completely break the language, as explained here. How would you prevent new variables in functions and loops and so on from accessing upvalues of the same name? You couldn't do it - you'd be forced to make sure every new variable in your script had a unique title. It'd be a royal mess.

lucy-san, on 11 January 2015 - 03:18 PM said:

Every goddamn variable should be local by default

ElvishJerricco, on 11 January 2015 - 11:43 PM said:

I just want brackets…

ElvishJerricco, on 11 January 2015 - 11:43 PM said:

Related to that point: Using multiple files in CC Lua is a nightmare. You have to use os.loadAPI, which means you can't have a .lua extension unless you override loadAPI manually. It also means your code is now in the global scope because why not? The other option is manually loading files but that's tedious. If we could just have a function similar to require…

ElvishJerricco, on 11 January 2015 - 11:56 PM said:

Unfortunately there's no fixing concatenation with LuaLua. The + operator must emit an add instruction. And it's the VM that determines how an add instruction works with string types. The reason I say it can't emit a concat instruction is this:

function concat(s1, s2)
  if type(s1) == "string" or type(s2) == "string" then --# Or whatever type returns
	return tostring(s1) .. tostring(s2)
  else
	return s1 + s2
  end
end

ElvishJerricco, on 11 January 2015 - 11:56 PM said:

I should point out that LuaLua is not a Lua VM. It's a Lua compiler. It just adds syntax to Lua and runs the resulting bytecode through ordinary means. There's no in-between except the compilation step, which is tiny.

lucy-san, on 12 January 2015 - 07:53 AM said:

Bomb Bloke, on 11 January 2015 - 10:40 PM said:

Removing "local" altogether would completely break the language, as explained here. How would you prevent new variables in functions and loops and so on from accessing upvalues of the same name? You couldn't do it - you'd be forced to make sure every new variable in your script had a unique title. It'd be a royal mess.

lucy-san, on 11 January 2015 - 03:18 PM said:

Every goddamn variable should be local by default

lucy-san, on 12 January 2015 - 07:53 AM said:

function concat(s1, s2)
  if type(s1) == "string" or type(s2) == "string" then --# Or whatever type returns
	return tostring(s1) .. tostring(s2)
  else
	return s1 + s2
  end
end

Bomb Bloke, on 12 January 2015 - 08:00 AM said:

lucy-san, on 12 January 2015 - 07:53 AM said:

Bomb Bloke, on 11 January 2015 - 10:40 PM said:

Removing "local" altogether would completely break the language, as explained here. How would you prevent new variables in functions and loops and so on from accessing upvalues of the same name? You couldn't do it - you'd be forced to make sure every new variable in your script had a unique title. It'd be a royal mess.

lucy-san, on 11 January 2015 - 03:18 PM said:

Every goddamn variable should be local by default

Yes, I saw that, and I'm saying that wouldn't work. How would you declare a new local with the same name as an old one? If it's done automatically the first time you refer to a variable in a function, then how would you refer to upvalues?

lucy-san, on 12 January 2015 - 07:53 AM said:

ElvishJerricco, on 11 January 2015 - 11:56 PM said:

Unfortunately there's no fixing concatenation with LuaLua. The + operator must emit an add instruction. And it's the VM that determines how an add instruction works with string types. The reason I say it can't emit a concat instruction is this:

function concat(s1, s2)
  if type(s1) == "string" or type(s2) == "string" then --# Or whatever type returns
	return tostring(s1) .. tostring(s2)
  else
	return s1 + s2
  end
end

Lyqyd, on 12 January 2015 - 07:48 AM said:

Nobody forces you to use os.loadAPI. I have lately been writing configuration files as valid lua, then doing something like what os.loadAPI does (set up its env table, run the file, then use the resulting filled env table) to load them up and make use of them. It's quite handy and doesn't pollute the global table.

ElvishJerricco, on 12 January 2015 - 08:55 AM said:

My point was more that the + operator can't be changed in the compiler to concatenate strings. I'm aware that Lua code can be written to handle doing either concatenation or addition. It's just that the + operator must equate to an add instruction.

ElvishJerricco, on 12 January 2015 - 08:55 AM said:

Lyqyd, on 12 January 2015 - 07:48 AM said:

Nobody forces you to use os.loadAPI. I have lately been writing configuration files as valid lua, then doing something like what os.loadAPI does (set up its env table, run the file, then use the resulting filled env table) to load them up and make use of them. It's quite handy and doesn't pollute the global table.

Well what I mean to say is that there is no decent way to work in multiple files without writing your own code loading system. You can, and it's not too bad but, but I think a better way should just be included in CraftOS

Requiem of Silence, on 11 January 2015 - 07:26 PM said:

lucy-san, on 11 January 2015 - 06:58 PM said:

>The thing is Lua works.
PHP works as well.
AFAIK lua was never meant to be a professional language, but a simple language for modding, etc. It gets job done, but it could get job done in nicer way. No language is perfect and lua is not bad, neither is excellent rough.

There are occasions when you have a game/engine that uses Lua. For example, World of Warcraft and Crysis1/2/3(Uses Lua along with C++) both use Lua.

MKlegoman357, on 12 January 2015 - 03:23 PM said:

Well, from my point of view Lua's 'require' is basically 'dofile' but with a little more functionality for managing libraries. 'dofile' works quite well instead of 'require'.

What I don't like about CC Lua is the lack of not just the debug library but all Lua's libraries. Literally, why CC doesn't have all the default Lua's libraries. In fact almost every library can be recreated in CC Lua so I do not see why, for example, the io library couldn't be completely added and functional in CC. And the package library with 'require'. And the debug library (allowed by config option). Why Dan? Why??

MKlegoman357, on 12 January 2015 - 07:44 PM said:

I suspect LuaJ has all the native Lua libraries built-in. But like I said, a lot of Lua libraries can be made in plain CC Lua.

MKlegoman357, on 12 January 2015 - 03:23 PM said:

Well, from my point of view Lua's 'require' is basically 'dofile' but with a little more functionality for managing libraries. 'dofile' works quite well instead of 'require'.

What I don't like about CC Lua is the lack of not just the debug library but all Lua's libraries. Literally, why CC doesn't have all the default Lua's libraries. In fact almost every library can be recreated in CC Lua so I do not see why, for example, the io library couldn't be completely added and functional in CC. And the package library with 'require'. And the debug library (allowed by config option). Why Dan? Why??

Lyqyd, on 12 January 2015 - 10:15 PM said:

So they can break the sandbox more easily. That might not be what it would be used for initially (it does have debugging uses as well), but that's the biggest thing it would be used for after maybe a day at most. We will likely never see it in ComputerCraft.

lucy-san, on 12 January 2015 - 02:33 PM said:

ElvishJerricco, on 12 January 2015 - 08:55 AM said:

My point was more that the + operator can't be changed in the compiler to concatenate strings. I'm aware that Lua code can be written to handle doing either concatenation or addition. It's just that the + operator must equate to an add instruction.

By compiler You mean LuaLua? I haven't read the code, but I'm pretty sure that this can be accomplished in one way or another :)/>

lucy-san, on 12 January 2015 - 08:30 AM said:

Same way You do now?

x = 0

for i=1,10 do
  x = x + 1
end

print x

Bomb Bloke, on 13 January 2015 - 06:22 AM said:

Certainly it wouldn't hurt to have the debug libraries accessible via config. There'd need to be some warnings attached, though - the typical server owner, if asked by one of their users to enable them, wouldn't have any idea as to the ramifications. Some commented lines in the config should suffice.

ElvishJerricco, on 13 January 2015 - 06:30 AM said:

Bomb Bloke, on 13 January 2015 - 06:22 AM said:

-spoiler-

Yea as it stands, debugging in CC can be a nightmare. I really don't see a reason not have this config option.

local function a()
  local a = "HELLO"
  local b = "ANOTHER"
  return a .. b
end

local function a()
  local a, b
  __pushStack(1, function() return a, b end)
  local temp = a .. b
  __popStack()
  return temp

Engineer, on 12 January 2015 - 09:37 PM said:

What's the point about reinventing the wheel?
anyway, I think Dan has reasons for the removal of those libraries. You'll live without those libraries, they are not life dependant

Bomb Bloke, on 13 January 2015 - 06:22 AM said:

Those were two mutually exclusive methods. I'm not sure what you're on about. :|

Let's say "local" is abolished, and you have this:

x = 0

for i=1,10 do
  x = x + 1
end

print x

Is the "x" that we're assigning to within the loop local to that loop, or does it refer to the pre-defined upvalue above the loop? That is to say, does the print statement at the end print 0, or does it print 10?

Let's say it's a new local. In that case, how would you make it refer to the upvalue? By constantly sticking an "upvalue" keyword in front of it? You'd end up typing that more often than you have to type "local" now. Re-assignments to upvalues typically occur far more frequently than new declarations.

Let's say it's the upvalue. What options would you have if you wanted to declare a new variable, short of using a unique title every single time? There goes that flexibility - you'd need to make absolutely sure you don't let your names collide.

These aren't insurmountable problems; but I'm not seeing a solution that isn't worse than the original issue.

lucy-san, on 14 January 2015 - 09:11 AM said:

Reusing names is not a good coding habit.