Open qwertie opened 5 years ago
Suggested edited keyword list: added redo
, test
; replaced except
with minus
, and using
with given
so that so that except
and using
can be binary ops instead.
// Keyword-statement initiators
// Simple statements (8)
goto return break continue redo throw case var
// Block statements (8)
function class if while do for switch try
// Expressions (2)
new delete
// "Future" JS reserved words (5) / type & namespace definitions (4)
interface import export package enum struct type alias namespace
// Other (9)
fn prop process construct data loop yield expect
// Literals (3)
true false null
// Continuators (10)
else elsif elseif catch finally until plus minus given
While I'm loathe to have too many keywords, I think it's important to distinguish the different kinds of readonly-ness; maybe there should be more keywords for variable decls? let
, const
... fixed
? I've also seen val
(value, i.e. unchanging) used. Finally there's D's immutable
concept, which is quite useful but a bit long - maybe imm
would be better?
let x = new Foo() // JS has it, and Swift uses it like C#'s `readonly`
fixed x = Foo.new() // Could for pinning like in C#, but I'm thinking of it
// as short for "fixed, i.e. read-only after initialization". "Fixed" also
// means "repaired"; multiple meanings for one keyword seems like a bonus
const x = Foo.new() // a popular keyword; I especially like how D uses it
imm x = Foo.new() // useful concept from D
Note that mutability can be a property of values, not just variables, and these keywords could potentially be used in the context of parameters and return values, or applied to the type rather than the variable.
concat(... stuff: const str[]): imm str => {
// btw, `result` is not a keyword, but I like the "return variable" concept
result = str.new
stuff foreach|> s => result.append(s)
}
I'm inclined to add a set of keywords to LESv3 so that code is easier to write and so that there is partial compatibility with JavaScript. The keywords will act identically to their dotted counterparts, e.g.
for
will behave identically to.for
.The original proposed set of keywords can be found here.
Reasons not to do it:
while
is a keyword, it seems like it cannot also be a continuator, implying thatdo...while
loops are not possible. A workaround for this would be to also introduce a specialdo...while
syntax. A workaround that doesn't make the lexer and parser more complex is to usedo...until
loops instead, but that's a strange asymmetry to create between while and do-while loops.Note that if LES becomes popular, the keyword set must be frozen, so it should be chosen with care.