Lua auto-complete?

[OmarShehata]

I was considering attempting to make my own version of Lua with brackets for everything, that would first compile to Lua, removing the brackets and placing indents where appropriate then compiling that Lua file. How hard/practical would that be? Perhaps someone could make a stricter version of Lua.

That sounds a lot like moonscript (it uses spacing instead of brackets, like Python).

The thing that really peeved me with Python is how annoying the spacings were, so I wouldn't be looking forward to using that. MoonScript does look pretty interesting though.

I didn't want to make a new thread for this so I thought I'd just say it here, but is it just me or is the fact that declaring a variable and assigning a value to a variable are indistinguishable a glaring design flaw?

While I found this: http://lua-users.org/wiki/DetectingUndefinedVariables It just seems to me like a convoluted way to solve a problem when all it would take is making it so that you need to type "var Varname = value" when declaring a value. So if you try doing:

myX = 2;

And myX was never declared before, it would give you an error. It's simple, and it would prevent a *lot* of headaches.

Now I'm not that experienced in programming to go around pointing design flaws in languages, but would there be *any* disadvantages whatsoever to enforcing proper declaration?

[Santos]

Killa may be of interest.

[Robin]

var is not a keyword in Lua. It's local.

[OmarShehata]

var is not a keyword in Lua. It's local.

That doesn't help.

If I do:

Code: Select all

local myXVariable = 2

--Then later

if myXvariable <= 10 --won't work. Won't throw an error.

Whereas

Code: Select all

var myXVariable = 2

if myXvariable <= 10 --Should throw an error because it wasn't declared

Killa may be of interest.

Oh god. I think I want to give this man all my money! Hopefully Killa is stable enough to use.

[Xgoff]

I was considering attempting to make my own version of Lua with brackets for everything, that would first compile to Lua, removing the brackets and placing indents where appropriate then compiling that Lua file. How hard/practical would that be? Perhaps someone could make a stricter version of Lua.

That sounds a lot like moonscript (it uses spacing instead of brackets, like Python).

The thing that really peeved me with Python is how annoying the spacings were, so I wouldn't be looking forward to using that. MoonScript does look pretty interesting though.

I didn't want to make a new thread for this so I thought I'd just say it here, but is it just me or is the fact that declaring a variable and assigning a value to a variable are indistinguishable a glaring design flaw?

While I found this: http://lua-users.org/wiki/DetectingUndefinedVariables It just seems to me like a convoluted way to solve a problem when all it would take is making it so that you need to type "var Varname = value" when declaring a value. So if you try doing:

myX = 2;

And myX was never declared before, it would give you an error. It's simple, and it would prevent a *lot* of headaches.

Now I'm not that experienced in programming to go around pointing design flaws in languages, but would there be *any* disadvantages whatsoever to enforcing proper declaration?

ideally lua would require all variables to be declared, but that would be annoying for many of lua's use cases (where globals don't matter since user code is in its own environment). there was an idea for a semi-required 'global' keyword, which would be optional until it was first used in a scope, at which point all further global declarations in that scope would have to use it. maybe a post-5.2 lua will support it

anyway, the solutions on those page are... a lot more complex than what you really need to detect undefined variables; they're basically searching the generated bytecode for the instructions that deal with global get/sets. sure, they find them (well, ones that aren't being eval'd) before you even run the script, which is nice.

if runtime detection is fine, something like http://codepad.org/T2YKKF9K will work. this actually shows an advantage of lua NOT taking the local-by-default route: a typo assignment will most likely become a global, which can be caught and indiscriminately banned (globals are evil etc)... in contrast to it becoming a new local, which may be catchable (depending on the language), but should definitely NOT be banned! it'll fail if your typo happens to match an existing global or local but this is less likely and would be hard to catch automatically anyway (how would it determine an intended binding from an unintended one?)

[kikito]

I sympathise with OmarShehata on the "global by default" business. After years using Lua, it still nags me. I'm firmly on the "nothing by default - neither local or global" camp.

It is possible to prevent a lot of the harm of "global by default" using XGoff's 3 lines of code. But this solution will work only in your code. If you try to use it with other libraries, it will fail if the other's try to declare a global variable "the standard way". That's why I think it should be done by default, with a specific syntax.

I've read that Lua 4.0 used some kind of notation to differentiate globals from locals - the % sign was involved. It was deemed (correctly) too cumbersome and dropped in 5.0, and that's where we are now. I hope they change it to something saner in Lua 6.x.

[Xgoff]

I sympathise with OmarShehata on the "global by default" business. After years using Lua, it still nags me. I'm firmly on the "nothing by default - neither local or global" camp.

It is possible to prevent a lot of the harm of "global by default" using XGoff's 3 lines of code. But this solution will work only in your code. If you try to use it with other libraries, it will fail if the other's try to declare a global variable "the standard way". That's why I think it should be done by default, with a specific syntax.

I've read that Lua 4.0 used some kind of notation to differentiate globals from locals - the % sign was involved. It was deemed (correctly) too cumbersome and dropped in 5.0, and that's where we are now. I hope they change it to something saner in Lua 6.x.

the % thing was for accessing upvalues, since lua didn't fully support lexical scoping then

[kclanc]

*necro bump*

I have implemented a proof of concept for the class-system-aware intellisense that I was talking about.

https://bitbucket.org/kevinclancy/love-studio/wiki/Home

There is an experimental demo in the downloads section that you could try if you have windows. If not, there are some youtube videos here that demonstrate it.
http://www.youtube.com/watch?v=NScJA1MuIfw

Only about two hundred lines of code are specific to typing the class system; I think this could be worth the effort for reasonably large projects. The downside to this is that there are certain things, such as tables and higher order functions, which the type checker does not even attempt to type. So the lack of intellisense when working with those items could confuse some programmers. Also, var args and functions with an undetermined number of return values have not been dealt with properly yet.

I noticed that there is also a commercial IDE called Lua Glider which has similar features.

[paulclinger]

(another necro bumb)

@OmarShehata: you can get this type of analysis (to detect typos) using lua-inspect. I've integrated it into ZeroBrane Studio IDE and it produces this type of report: static analyzer screenshot.

You can also get auto-complete, although it cheats a bit and simply does syntax analysis for those classes it knows about; for example, if it know about class Foo:bar and Foo:baz and you do "f = Foo.new()" and then start typing "f:" it will offer you "bar" and "baz" as two options. It wouldn't work in its current form for function parameters and custom classes.

[Desty]

@OmarShehata: you can get this type of analysis (to detect typos) using lua-inspect. I've integrated it into ZeroBrane Studio IDE and it produces this type of report: static analyzer screenshot.

You can also get auto-complete, although it cheats a bit and simply does syntax analysis for those classes it knows about; for example, if it know about class Foo:bar and Foo:baz and you do "f = Foo.new()" and then start typing "f:" it will offer you "bar" and "baz" as two options. It wouldn't work in its current form for function parameters and custom classes.

Hello Paul,

Could you elaborate on how you got lua-inspect to work? I installed it in Vim and it reports a series of errors like this:

Code: Select all

...\love\tutorials\intro\main.lua|1 col 10| unknown global love
...\love\tutorials\intro\main.lua|1 col 15| unknown field load

Presumably this is because the "love" module is implicitly loaded by the love interpreter front-end, rather than explicitly "require"d in programs.