3 ms·

Totally right. I was aware that this "overloading" does not imply ambiguity for the parser; it's just that i find it confusing to read in some cases (like the t

Totally right. I was aware that this "overloading" does not imply ambiguity for the parser; it's just that i find it confusing to read in some cases (like the tuples in Python, or the {} in JS), and i think it's curious that language designers deliberately choose to use the same symbol for totally different things when they could use something else, or keep the grammar simpler. I guess it's always a trade-off between simplicity at the grammar level and ease of use, but i'm not so sure about that either. Smalltalk has a very simple grammar, yet that doesn't make it harder to use than other languages with similar semantics; e.g. Ruby, which prefers to be "programmer friendly" by having multiple syntactic forms for denoting blocks, even a special syntax for calling function whose last parameter is a block, and much much more.

masklinn 14y ago
> i think it's curious that language designers deliberately choose to use the same symbol for totally different things when they could use something else, or keep the grammar simpler. The problems is that there's only a limited number of symbols available in ASCII, especially "matching"/"paired" symbols where you've got all of three pairs to work with (`{}`, `[]` and `()`), with one pair having a lot of immutable baggage (`()`) and one being coopted by C's inheritance (`{}`). (I'm not counting `<`/`>` as they have even more historical baggage as comparison operators) Now of course we could use non-paired symbols even for paired situations, but I guess these symbol pairs look... right? Especially for situations where we're defining a "section" or "grouping" rather than a coherent block (such as a string)