pgimeno wrote:Is your aim to retain compatibility with Lua, at least for the not very advanced features? I see problems with that.
Not
really looking for compatibility here. Just wanting it to look
like Lua, since I like the way Lua looks, but not all of how it functions.
I listed compatibility on the README, but I'll just go ahead and throw that out the window right now, because that seems pretty much impossible if I want to move forward at all without adding a trillion keywords.
airstruck wrote:
I did want feedback, and I appreciate it. I should mention that this is more of a hobby than anything else, since I've just had a growing interest in language implementations as of recent, which made me wonder the question of: if I could change one or more things about the language I like the most, which would those be? That's mostly irrelevant though, but some background, so I don't try to make it seem like I'm trying to break any new ground in the Lua world, or anything like that. I'd honestly be surprised if this made it anywhere past the translation stage.
Another thing I want to point out, is that it's less about "saving keystrokes" more than it is just making it look a little easier to read on the eyes, and to add some functionality that just seems annoyingly missing in some areas. Even then, saving keystrokes on small things makes a big difference over time.
The assign proposal is just an option of many, as I'm still mostly trying to figure out, if going forward with 'everything is an expression', what kind of sensible value a loop should return, and the general consensus is a table. The implementation details of that are the tricky part, so your point isn't invalid. I've thought about just tossing all loops out the window if I somehow could, and just using one statement for iteration, somehow. Maybe. But, again, one of many options. Have yet to arrive at what seems most fitting for Luna.
The import syntax is just there because it, in my opinion, just looks and reads a hell of a lot nicer than a typical require. The rules on what it does would be documented explicitly, and you'd know what was being assigned. Optionally, I could have a statement similar to
JavaScript's import, but I didn't want to look to anything too verbose, and I wanted something that could still be made sense out of.
I share your opinions on locals, though. 100%, really. I've always favored explicit scope declarations. What I
haven't favored is having to cross-declare functions or other variables at the top of a scope for any other function to be able to access them.
Code: Select all
local function foo()
bar = bar + 1
end
local bar = 0
foo()
This is a simple example that's probably better fixed by passing bar as a parameter, but this problem crops up a lot in Lua.
In that regard, moving to auto-scoped variables was maybe not the best idea, then. I can still have explicit locals, but instead just have them all automatically localized at the top still. That seems alright.
All that aside, the biggest challenge is definitely justifying the move from just pure Lua to a transcompiler, for problems that can be solved through other simple means in Lua alone. Still, that's where the improvement of the language itself comes in. Optionally, it could just become its own thing? Who knows. ¯\_(ツ)_/¯