LÖVE

That's still a good idea, yeah. I'll look into that some other time.

Here's my first attempt at converting it into a Bison input file:

http://www.formauri.es/personal/pgimeno ... luna.bison
I may have made mistakes. Operator precedence still needs to be defined.

This is a really neat project! Here's some ideas:

* Write a transcompiler in LunaScript that converts Lua to LunaScript. Then, run the transcompiler on your original code. I think there's a word for this... self-hosting?
* Write a transcompiler in Lua that converts LunaScript to Lua. See how far the rabbit hole goes.

I'm gonna put it aside for now, actually. For a lot of the reasons airstruct pointed out, and for a few others, which might be restatings of what's been said anyway:

1) There's not a lot of ways I can create a new language that's based on Lua without being redundant or without becoming what MoonScript is, which really exemplifies the many reasons behind why Lua does what it does.
2) Don't have as much time as I'd like to put into something like this.

Though MoonScript has a lot of quirks and "missing features" of its own in some places, I'll step aside and let it do the work for now. No impostor syndrome here, just being realistic with what someone like me can actually go forward with.

Kingdaro wrote:I'm gonna put it aside for now, actually

What about creating a Lua minifier instead? It's been done, of course, and maybe isn't that useful for Love where everything's zipped anyway, but it might be a good excuse to play around with ASTs in Lua. Could add more features down the road, like concatenating multiple scripts into one (TsT has experience with that if you're interested; he's a friendly and helpful guy and I'm sure he'd find the time to share his thoughts).

There are other Lua->Lua transformations that could be useful also. In particular, something to "unroll" closures while keeping the same behavior would be really interesting to me. I'd love to be able to write minimal, straightforward code with closures, and then have some automated process eliminate the closures while keeping the same behavior. That way I can write clear and compact code, and wouldn't have to build anything to test the code as-is, but could squeeze some extra performance out with the build process.

I have some other ideas about Lua->Lua transformations, mostly regarding code generation and LuaJIT optimization, but I need to think about it a bit more. Anyway, if you're interested in that kind of thing let me know and we can discuss.

My main problem with Lua is that locals and globals are backwards. Variables should be local unless explicitly declared as global, not the other way around, as that leads to too many inadvertent mistakes. That, and the lack of a ternary operator. I'd be happy with just "'if then else' is an expression" rather than with "everything is an expression".

Yeah, I now remember one ambiguity with assignment as an expression: How should that be parsed? Is d being assigned or used as a value for b?

That's something to consider in case you or someone else wants to take on it again.

pgimeno wrote:Variables should be local unless explicitly declared as global, not the other way around

This has been widely discussed and the general consensus has been that local-by-default would be just as bad as global-by-default, if not worse. The problem with local-by-default is that people might actually use it, producing code where the entire meaning changes when you add a variable in an outer scope with the same name as an existing implicitly-declared local in an inner scope. With global-by-default, you at least know that if something is an implicit declaration, it lives in the global scope, and most of the time when you see implicit global declarations, it's happening in the outermost scope of a module (if it's happening inside a block scope, it's usually either laziness, or an accident, or someone just doesn't know any better).

Of course, it might be best if assignment to an undeclared variable were a runtime error, and no implicit declarations were allowed. At least we can get that behavior by supplying a __newindex metamethod for _G that throws an error. With local-by-default, you wouldn't have that option.

the lack of a ternary operator

Logical short-circuiting should be good enough most of the time. Yeah, you run into cases where you want to write something like this, but can't:
But in most cases you can just reverse the condition (and probably drop the "or false" / "or nil" as well):
There's only one case where you can't make it work it by reversing the condition. That's the case where you want the expression to evaluate to false on one hand and nil on the other. I doubt this scenario is very common in practice (I've never run into it, anyway).

airstruck wrote:The problem with local-by-default is that people might actually use it, producing code where the entire meaning changes when you add a variable in an outer scope with the same name as an existing implicitly-declared local in an inner scope.

Yeah, I didn't think that through. Thanks for the pointer. This sums it up pretty well:

[6] "The problem is that without [explicit] local declarations, you cannot say where the variable is local to." (RiciLake)

Making both explicit might work then, maybe. With a shortcut symbol for locals, e.g. @myvar = 0 meaning local myvar = 0. I'll think more about it.

pgimeno wrote:Making both explicit might work then, maybe. With a shortcut symbol for locals, e.g. @myvar = 0 meaning local myvar = 0. I'll think more about it.

For combined declaration and assignment, I like the idea of having a dedicated operator; could borrow := from Go, maybe.
Maybe you could extend this to explicitly typed variables, borrowing from Pascal (might conflict with other syntax though):
For declarations without assignments, you could still do "local foo," although "foo := nil" is only one character longer (or one character shorter if you're the kind of programmer who treats whitespace like it costs money).