Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Neat. Lots of good stuff.

What's the interplay between infix notation and operator precedence? Expressions are not infix?

Also, please explain the dictionary and set duality.

FWIW, in my toy language, I use one syntax for sets, lists, and arrays, delimited with brackets '[' and ']'. Whereas maps, dicts, and (prototypical) objects use curlys '{' and '}'. A la JavaScript et al.

Lastly, wrt using '++' for concatenating lists, there have been times I've wanted sugar for prepending to a list. So maybe support both 'atom ++ list' and 'list ++ atom'?

For future updates, please us posted.



I'm the author but not the OP. Thanks!

I'm not sure I follow the question about infix notation and precedence, but: Trains of identifiers like `a b c d e f g` are always parsed as `b`, `d`, `f` being infix binary operators; their precedences are looked up at runtime to decide how that expression evaluates. Explicit function calls and indexing always bind more tightly, and operands in those trains can contain either; an expression like `a(arg) b c(arg1, arg2) d e[i] f g[j:k]` has the same binary operators as before. But operators are only single identifiers and don't contain function calls, so `a b (c)` is still the binary operator `b` with arguments `a` and `(c)`.

"Sets" are just dictionaries with set elements as the keys and null as every value. This makes sense because you want testing for set membership to be fast like locating a key in a dictionary and because, like in Python, iterating over a dictionary iterates over its keys.

We also already have `.+` for prepending a list element to a list and `+.` for appending. (These are the analogues of Scala's `+:` and `:+`.)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: