Hacker News Reader

Comment by sillysaurus3 | Hacker News Reader

Commas are unnecessary. There is zero benefit to having them. The code is actually easier to parse if you just remove them from the rules list entirely. No commas might look weird for a day or so, but you quickly get used to it.

(I'm ignoring the comma operator, which is a special case and not relevant to the main point.)

View on HN

    foo(x, -y)

is not the same as

    foo(x -y)

(from your last sentence, I assume you were talking about JS in general, not just JSON)

Mm, fair point. Infix math rears its ugly head again. I've been living in Lisp a bit too long.

Never mind.

Actually, let's double down: Instead of writing 1+2, you should really be writing +(1 2). Don't you see how much easier that would make things? A single, uniform syntax everywhere! + is just a function that gets called like anything else! Your foo(x -y) example would become foo(x -(y)).

I'm mostly joking.

Haskell makes a reasonable job of combining infix operators with no commas between function arguments[1]. You sometimes end up with a few extra parentheses and $s instead, but things generally seem to work out.

Does use commas for lists and tuples, though. The latter kind-of make sense, it's the commas that identify the expression as a tuple. Not sure what the rationale for commas in lists is, though.

[1] Slightly complicated by currying (arguably, it's several successive function applications rather than one multi-arg application) but the end result is the same...

> Not sure what the rationale for commas in lists is, though.

Well, you need some separator, and spaces won't do since [x y] has x applied to y.

Good point.

Although could, in principle, make space-between-list-items higher precedence than function application. E.g.:

    [x (func y) z]

But how do you write a list with only one element, x (func y) z?

[(x (func y) z)]

It's not infix math that's the problem, it's the ambiguity of "-". It can take two arguments in one context, or one in another (or just be a representation of a negative number without implying any function call at all.) If we just used a different symbol for subtraction, it would clear up a number of other parsing problems languages run into. Or you could just require negations to be done inside parentheses.

Or just require whitespace for binary - and no whitespace for unary.

  res = -x ==> negative x

  res = c - x ==> c minus x

  res = - x ==> syntax error

I like OCaml's terse syntax. You can write something like that as just "foo x (-y)" (the brackets are only needed because of the use of minus but can usually be omitted).

Not really suggesting this, but if we only allow the unary operator - to always be stuck next to the number, and the binary operator - to always be surrounded by whitespace, it is. So:

  foo(x -y) => foo(x, -y)

  foo(x - y) => foo(x - y)

They exist because of string concatenation. In some languages any consecutive strings are implicitly concatenated so that you can have a very long string split across many lines.

Reply on news.ycombinator.com