Hacker News Reader

Comment by nikolay | Hacker News Reader

Nice, but I always wonder why function is abbreviated as the longer unambigous fun and not just fn?!

Jordan here (I work on Reason):

I agree with you but one benefit of `fun` is that it aligns better with multiples of two spaces. It's important when lists end up wrapping:

    /* Nice multiple of two spaces */
    fun myFun
        xyz
        abc => {
      doSomeThings(xyz, abc);
    };

    /* yikes, only one horizontal space between
     * doSomething and abc on the line above */
    fn myFun
       xyz
       abc => {
      doSomeThings(xyz, abc);
    };

I'm obviously no stranger to bike-shedding!

Not a good enough reason, sorry! With syntax coloring, it's less irrelevant as well.

When we start talking about syntax coloring, you know we're just one step closer to actually debating the color of a literal bike-shed!

Jokes aside, what would your highlighting do in this case?

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.

I know Rust uses "mod", but Rust is consistent and predictable - it also uses "mut" unlike in Reason.

Regarding ":" to denote type - I like it and it's widely used across various language, but not enforced with parentheses for typecasting.

Reply on news.ycombinator.com