3 ms·

I had the pleasure of working with Lua 5.1 back in the late noughties. For me it replaced Tcl whenever I wanted something I could configure above a C library.

I had the pleasure of working with Lua 5.1 back in the late noughties. For me it replaced Tcl whenever I wanted something I could configure above a C library. At the time I used it I found it quite nice but I'll also not forget the hours I wasted tracking down nil table corruptions which could have easily been caught by a type checker. I had some hope that Luau https://luau-lang.org https://luau-lang.org or Teal https://github.com/teal-language/tl https://github.com/teal-language/tl would make things better but with the following example function foo(x: number): string if x == 2 then return nil else return "foo" end end x = { foo(1), foo(2), foo(3) } for i,v in ipairs(x) do print(i,v) end they produce no warning and sadly only print 1 foo When I was younger I might have put up with that sort of WTF but now that I have better options I try to stick to type checked languages where I don't have to.

caligian 3y ago
There is no 'corruption' happening anywhere. When you register local variables, they are merely defined as register locations and have a default value of nil which is absence and hence memory saved. They would have to mark nil explicity as a new data structure which is probably wastage as they would have to allocate memory for every variable declaration that may or may not be used. It is just nil, nil at a literal level with the exception being local variables which are handled differently as offsets to register locations than other dynamic languages without such 'local' qualifiers. That should explain why variables can be nil but not ta les. You can hash nils but it would take up memory. I don't think it's logical to use memory for something you are already marking as absent. Why not use false instead?
caligian 3y ago
This is one of the things i was talking about. You cannot map nil to a key because nil means absence. The compiler can only infer such absence at a control flow level aka passing arguments to functions or checking nil-variables. You are supposed to use false in such a case here
- srhtftw 3y ago
  To me this is a serious flaw and I simply refuse to accept that it's beyond criticism. No language should allow its collections to be corrupted this easily. Especially when a key use of the language is configuring other software. Fortunately there are other configuration languages available now besides Lua which provide type checking, so I remain hopeful that a future version of Lua or one of the newer typed Lua variants will eventually learn from those.
cxr 3y ago
> I found it quite nice but I'll also not forget the hours I wasted tracking down nil table corruptions which could have easily been caught by a type checker. > I had some hope that Luau https://luau-lang.org https://luau-lang.org or Teal https://github.com/teal-language/tl https://github.com/teal-language/tl would make things better Inline type annotations are not a prerequisite for typechecking; there's nothing stopping you from writing straight Lua (or whatever) and then having a separate tool that does typechecking _without_ having to change the language. People are failing to take away the most important lessons from TypeScript. The same goes, frankly, for languages that ostensibly have typechecking but have such deficient type systems that it's not exactly that much better than not having one. (Like C, for example.) Considering that type annotations are more valued for being a form of documentation than they are valued for making it easier to write the compiler's code generator... If you have a function like printf that is ostensibly typechecked but not really, and you already have documentation (like man pages) for that function that says that the arguments need to be such-and-such, but the typechecker for your compiler/IDE isn't able to factor that in at or before build time, then that's a compiler/IDE problem, not anything that necessitates a change to the original grammar.

caligian 3y ago

There is no 'corruption' happening anywhere. When you register local variables, they are merely defined as register locations and have a default value of nil which is absence and hence memory saved. They would have to mark nil explicity as a new data structure which is probably wastage as they would have to allocate memory for every variable declaration that may or may not be used. It is just nil, nil at a literal level with the exception being local variables which are handled differently as offsets to register locations than other dynamic languages without such 'local' qualifiers. That should explain why variables can be nil but not ta les. You can hash nils but it would take up memory. I don't think it's logical to use memory for something you are already marking as absent. Why not use false instead?

caligian 3y ago

This is one of the things i was talking about. You cannot map nil to a key because nil means absence. The compiler can only infer such absence at a control flow level aka passing arguments to functions or checking nil-variables. You are supposed to use false in such a case here

srhtftw 3y ago
To me this is a serious flaw and I simply refuse to accept that it's beyond criticism. No language should allow its collections to be corrupted this easily. Especially when a key use of the language is configuring other software. Fortunately there are other configuration languages available now besides Lua which provide type checking, so I remain hopeful that a future version of Lua or one of the newer typed Lua variants will eventually learn from those.

cxr 3y ago

> I found it quite nice but I'll also not forget the hours I wasted tracking down nil table corruptions which could have easily been caught by a type checker. > I had some hope that Luau https://luau-lang.org https://luau-lang.org or Teal https://github.com/teal-language/tl https://github.com/teal-language/tl would make things better Inline type annotations are not a prerequisite for typechecking; there's nothing stopping you from writing straight Lua (or whatever) and then having a separate tool that does typechecking _without_ having to change the language. People are failing to take away the most important lessons from TypeScript. The same goes, frankly, for languages that ostensibly have typechecking but have such deficient type systems that it's not exactly that much better than not having one. (Like C, for example.) Considering that type annotations are more valued for being a form of documentation than they are valued for making it easier to write the compiler's code generator... If you have a function like printf that is ostensibly typechecked but not really, and you already have documentation (like man pages) for that function that says that the arguments need to be such-and-such, but the typechecker for your compiler/IDE isn't able to factor that in at or before build time, then that's a compiler/IDE problem, not anything that necessitates a change to the original grammar.