It would make the function name stand out from the parameters. Again, to pick one unintuitive abbrevation, just because it's a 3-letter one like let, it's just not serious! Make all be 3:
type -> typ
switch -> swi
if -> iff
else -> els
in -> inn
downto -> dow
module -> mod
Call you language 3-letter reason. You see how it ridiculous it gets? You can't make all keywords be 3-letter and if people care about alignment, they can further align, but most don't care as much as you think!
It doesn't have to be three letters, keywords can be odd numbers and achieve a similar effect - also, we likely will use the `mod` keyword instead of `module` fwiw.
That would be another poor choice as "mod" is used as "modulo" - there's no need to abbreviate "long" words like "module", because they are not used so often and bringing ugliness and confusion just to save a couple of characters per file is not worthy!
In this case, you don't even need the "fun" keyword as syntax-wise, "=>" alone can be used like in other languages as (parameter1, parameter2) => parameter1 + parameter2, for example - it's obvious enough without having to prefix with anything!
Anyway, I see that you want to be "different" in hopes to be "better", but, indeed, you're just "weird", instead.
"+." for float addition, "^" for concatenation, etc.
"(" <val> ":" <type> ")" instead of the shorter and more readable <val> "as" <type>.
For example, why did you choose "mutable" and not "mut"? See, your language is full of inconsistencies, it's not well-thought, it's not intuitive! For example, you chose "rec", which usually means "record" for "recursive"! In your "for"-loop, you have just "to", not "upto", but then "downto"! A good choice borrowed by some old languages would be to use the optional "by" <step>, which defaults to +1, but in a case of a "downto", would be -1, and thus giving you a more powerful loop!
You don't know of any other languages that use `mod` to represent "module"? Say, perhaps, the one you just advocated for in another thread?
And there are in fact issues with using x => y syntax for lambdas without a leading fun/fn keyword:
let x =
(this,
is,
a,
really,
long,
thing
) => 10;
- In that example it's not possible to tell if the leading ( is the start of a pattern for the sake of lambda, or a tuple. This happens with ES6 today as well (destructured record argument). It's not just a matter of human readability, it's a matter of building an efficient parser.
- The (x : y) syntax for type annotations is not new or weird to many people. That's the syntax used by ML, OCaml, and JS (Flow).
- We're likely going to swap some operators for string concat, so that it would be the more common ++ operator.
- The rest of the observations are good and we should address them soon.
