The "I Love Lua, but..." post

[miko]

Lua's "global by default" idea. I think a "local by default" or even a "nothing by default" (i.e. you always have to specify either "global" or "local" are better, except for maybe trivial programs.

That one annoys me too. I would prefer if variable scoping was like it is in C++: only visible the block they are defined in and it's subblocks.

You mean like this below?

Code: Select all

local a,b=1,2
print(a,b)
do
  local a,b=3,4
  print(a,b,c,d)
  do
    local c,d=5,6
    print(a,b,c,d)
  end
end
print(a,b,c,d)

[Xgoff]

since i dont have much of an opinion on the c api...

• Lua's "global by default" idea. I think a "local by default" or even a "nothing by default" (i.e. you always have to specify either "global" or "local" are better, except for maybe trivial programs.

local by default: ugh... i enjoy having quite anal control over the scopes of my locals
nothing by default: i would be fine with this, however for eg batch script applications or programs where having globals doesn't matter, this would get quite annoying. seeing as there is either strict.lua or putting __newindex on _G, there probably isn't a desperate need for this

• The : operator. I would have preferred that foo.bar(baz) included foo as the first parameter of bar by default. I would not mind that the : operator was put there for the opposite case. Incidentally, I would not mind if "self" was implicit in all functions. In short: I prefer the Javascript way.

dont forget that 'foo.bar(baz)' actually means '(foo.bar)(baz)'; you're not calling a function, you're indexing the table then attempting to call whatever value you got back. plus, lua can't really pass that table reference anymore since it gets lost once 'bar' is retrieved. the colon syntax basically exists to allow this without clashing with general indexing, which is done a lot more often. really, if you want dot syntax for methods, just use closures.
iirc the reason javascript can get away with dot methods is that, behind the scenes, it tries to find its 'this' reference somewhere. a quick google search can explain how well that tends to work at times. conveniently enough, lua's colon syntax dodges this issue quite effectively.

• Lua doesn't handle directories natively. This makes using require() very frustrating, because you can't use relative paths. The fact that folders are not supported on ANSI C doesn't justify that they aren't in LUA IMHO. If you are not going to acknowledge that there's a filesystem underneath, then don't give me a require() function, and make me require stuff from C. Or at the very least, give me a require function that can be used with relative paths.

well, as mentioned, you CAN add paths for require to search (including relative paths), but you have to give it the exact path to the .lua or .dll/.so/.whatever, save for the ? you can use to represent the current module name.

• That the standard libs offer so little - specially table and string. I don't like inconsistency on what is provided and what not. math for example has sin and cos, but then it has foor but not round.

i can agree with this to an extent, and i kinda do wish there was a string splitting function (yes i know i could just use gmatch), and a deep-copy function for tables... of course these are two functions that have several possible ways of being defined

however, packing lua full of libraries would be an inconvenience to one of its most appropriate applications: embedded systems. really, if anything, it needs an officially-endorsed luaforwindows type of deal for the major operating systems; not the official distribution but a highly-visible third-party one

• Related to the previous one: Lua invents its own regexp, and then bases most of its string-related stuff on it.

doesn't really bother me since lua's patterns actually sufficient 95% of the time... otherwise i'd just use lpeg

all i ever miss from lua's patterns is grouping and alternation

• list-returning function calls used as parameter only "expand" if they are the last parameter. Otherwise, they return the first value only. I think this is done because some functions in the standard lib actually return two values, and people can use them without noticing anything, treat them as returning one value, and the code will work. I would prefer having two versions of the methods in the library - the "usual" one returning just the first value, and an "extended" version returning all of them, and expanding all functions.

yes, i hate this, but fortunately it's extremely rarely that i run into it

well, i think the reason it's actually done is just a side effect of how lua adjusts list lengths. however instead of duplicating functions for this it'd be better if:
1) lua didnt perform automatic list adjustment for nested lists (they could always be manually truncated with parentheses) -or-
2) there would be a syntactical way to indicate that a list should be kept expanded

obviously i would prefer the first, but it'd break backwards compatibility which would probably be worth it imo

• Local variables are second-class citizens. You have to use the debug lib for manipulating them. That should be built-in: if I have a _G, I'd also like to have a _L.

i dont think an _L is really possible since locals are registers and not table entries

• metamethods aren't looked up using __index. This is kind of a edge case, but it's giving me lots of trouble with middleclass-extras: if table t1 has t2 as its index table (getmetatable(t1).__index=t2), and t2 has an index in t3, and t3 defines a method called __tostring, then tostring(t1) should use that method. Well, it doesn't, because in Lua metamethods are looked up differently than regular methods (with a rawget on the metatable, not with metatable.methodname)

this is probably done because you could end up in some nasty situations with an __index calling itself recursively... i did get bit by this once but it was with a pretty tacky implementation of object properties, so

i usually don't do anything much more complex than a simple proxy table system pulling methods from a shared method table, though, but it works well enough for me

• Not being able to use the dot notation on table members when the keys are reserved words. I'd really like to be able to say my.function = function() instead of my['function'] = function() ... . And yes, I can say my.func instead. I still don't like it. This bugs me because it is a trivial parsing problem.

yes, this would be nice, although it could potentially drag other problems with it

• ~= instead of !=, and .. instead of +

really the first is just a syntactical difference; you could just as well argue that lua should use curly braces or significant indentation or require programs to be written backwards

although i really don't know why you would want addition and concatenation to share the same operator; when you're glancing through source code something like a + b + c + d + e + f is going to be a lot easier to follow if you know that + will only give you a number (or an error)

[thelinx]

Excellent replies. I myself don't really have any issues with Lua, I'm just here to agree with Xgoff.

[kikito]

Hello Xgoff, nice to meet you! I also think that your replies are very good. Most of our disagreements are really a matter of taste. I knew javascript well enough knowing Lua, so I might be a bit ... "spoiled" . And now ruby ... ok let's not get into that path.

One question though:

I enjoy having quite anal control over the scopes of my locals

I don't understand this. How would having locals by default not permit you to have control over that?

[BlackBulletIV]

And now ruby ... ok let's not get into that path.

Ha ha! Yeah, I've gotta resist "Ruby-bashing" languages all the time.

[Xgoff]

Hello Xgoff, nice to meet you! I also think that your replies are very good. Most of our disagreements are really a matter of taste. I knew javascript well enough knowing Lua, so I might be a bit ... "spoiled" . And now ruby ... ok let's not get into that path.

One question though:

I enjoy having quite anal control over the scopes of my locals

I don't understand this. How would having locals by default not permit you to have control over that?

this explains it better than i could

[tentus]

The biggest things I find myself missing is ++ and +=. It's way easier to write:

Code: Select all

foo += bar
foo++

than it is to write:

Code: Select all

foo = foo + bar
foo = foo + 1

[Lafolie]

I won't pretend to fully comprehend (ha) what you're all saying, but I'll add something:

I really dislike the "then" keyword. Mainly because I'm not used to typing it so I forget it alot.... but to me it's the same thing as having line end thingies, like semi-colons in PHP for instance. I like python for this because it's all done with tabs/indents and stuff. Am I making any sense?

What I mean is: "then" annoys me.

[Jasoco]

The biggest things I find myself missing is ++ and +=. It's way easier to write:

Code: Select all

foo += bar
foo++

than it is to write:

Code: Select all

foo = foo + bar
foo = foo + 1

Ugh! Me too! When I first came over from JavaScript, I found myself doing that all the time.

[snake]

[*]Lua doesn't handle directories natively. This makes using require() very frustrating, because you can't use relative paths. The fact that folders are not supported on ANSI C doesn't justify that they aren't in LUA IMHO.

Lua is written in ANSI C and I am very glad it is since this makes sure it is ultra-portable and can run on every OS supporting ANSI C.

.. instead of +

Addition of Number and concatenation of strings is totally different from each other, so of course it makes perfectly sense that both are not the same.
It is only confusing because you can use "+" also for the later in some languages.
So Lua devs did it right.

The biggest things I find myself missing is ++ and +=.

Well that is just syntactic bloat that doesn't add you more functionality.
If you have autocomplete, it isn't that much more to type in the lua way and I personally find it a lot more readable that way.

I really dislike the "then" keyword. Mainly because I'm not used to typing it so I forget it alot.... but to me it's the same thing as having line end thingies, like semi-colons in PHP for instance. I like python for this because it's all done with tabs/indents and stuff. Am I making any sense?
What I mean is: "then" annoys me.

Even Python has an ":" at the end and I used to forget about it all the time.
At least it "then" is more vieawble.
Also it should be possible to get the editor to add the "then" automatically for you.

What is dislike about Lua.
Well I haven't really found anything where I think the Lua devs has made an actual mistake on the design of Lua.
Maybe there are small things that could be improved but I tend to forget about them anyway so they cant be too crucial.
I miss the "code and data are the same" stuff of Smalltalk and Lisp sometimes but hey it is a fucking ALGOL-based language so you cant really complain about it.