Interesting, apparently the source also includes a (modified) version of the PUC Lua VM. Why don't they just generate bytecode for the existing VM and leave it as is (unless the modified version somehow would significantly increase performance)? What changes were necessary to the original VM to implement the language?
Seems logical to me. 1 = break the current level, 2 = break 1 level up, 3 = break 2 levels up, etc.
If you would do it the other way around, and then if you would add another for loop around the others, the breaks will break. You wouldn't expect that if you're modifying this code without looking at the current breaks or knowing about the break behavior.
If you however move the break statements inside a new for loop, at the most inner level, it would seem obvious that you have to update the break numbers.
What's poor about it, the numbers in the example? Think of them as inner/outer instead of "1" and "2". Without this kind of break statement, what do you do when you want to exit the outer loop, something like this probably:
local stop = false
for i = 1, 10 do -- outer loop
if stop then break end
for j = 1, 5 do -- inner loop
break -- to break from inner loop
stop = true; break -- to break from outer loop
end
end
So this new feature fits with the general theme of pluto being a very-sugared lua.
The reason one might find this cumbersome or problematic, is in the case of very large numbers of lines of code - sure, your example is visible and somewhat readable (arguable) in its current form - but tell me you won't have issues when the loop is 80 or 100 lines of code, and you need to add another inner loop as part of the development process.
Are you now going to go through and be sure all your breaks are numbered properly? Are you really, though?
Better, imho, would have been to introduce labels and "break <label>", but even that is going to cause more headaches than its worth.
Ultimately, one shouldn't write such horrid code anyway.
"Pluto aspires to be a version of Lua with a larger feature-set, that is all. Pluto is not a Lua-killer, an attempted successor, or any of that. Many people (rightly so) love Lua precisely because of the design philosophy. And fundamentally, Pluto is a major deviation from Lua's design philosophy. Some may prefer this, some may not."
Interesting, apparently the source also includes a (modified) version of the PUC Lua VM. Why don't they just generate bytecode for the existing VM and leave it as is (unless the modified version somehow would significantly increase performance)? What changes were necessary to the original VM to implement the language?
Some features like break N and default function args seem to be incompatible with the vanilla lua vm.
Well, this is a very poor design, one which makes me think what is the purpose of this project in the first place?
https://pluto-lang.org/docs/New%20Features/Break%20StatementSeems logical to me. 1 = break the current level, 2 = break 1 level up, 3 = break 2 levels up, etc.
If you would do it the other way around, and then if you would add another for loop around the others, the breaks will break. You wouldn't expect that if you're modifying this code without looking at the current breaks or knowing about the break behavior.
If you however move the break statements inside a new for loop, at the most inner level, it would seem obvious that you have to update the break numbers.
What's poor about it, the numbers in the example? Think of them as inner/outer instead of "1" and "2". Without this kind of break statement, what do you do when you want to exit the outer loop, something like this probably:
So this new feature fits with the general theme of pluto being a very-sugared lua.This is just poor language design.
The reason one might find this cumbersome or problematic, is in the case of very large numbers of lines of code - sure, your example is visible and somewhat readable (arguable) in its current form - but tell me you won't have issues when the loop is 80 or 100 lines of code, and you need to add another inner loop as part of the development process.
Are you now going to go through and be sure all your breaks are numbered properly? Are you really, though?
Better, imho, would have been to introduce labels and "break <label>", but even that is going to cause more headaches than its worth.
Ultimately, one shouldn't write such horrid code anyway.
I guess it is inspired by De Bruijn index[1].
[^1]: https://en.wikipedia.org/wiki/De_Bruijn_index
That's... interesting.
Curious how this compares with Luau: https://luau.org
Or Luon: https://github.com/rochus-keller/Luon
Basically a more convenient/intuitive Lua for JS/C/Java/C++ users, plus optional static typing. May in fact use this instead of Lua.
Yea. I am definitely trying this out too. It really has some new features changes that I wished lua had.