you can high up you rank in fortnite by using www.proboosting.net
sadf
I know we're all used to operator precedence from elementary school and in
programming languages, but beyond the very basic rules, most people find them
very confusing -- especially with semantics vs syntax (e.g., many people assume
<< in C has the same precedence as * because they are both mult
I see, that makes sense.
> special casing has been written into the parser
Last time I checked Nim had a grammar and the parser reflects the grammar...
> let's see what breaks accepted
I spent a morning trying to implement that RFC, which was supposed to be a
simple change in operator precedence for `.*` I soon found that much special
casing has been written into the parser around 'x.y' and that 'precedence' is a
fuzzy beast indeed
Nim was designed to be parsable without a symbol table and this feature would
break this design. You can come up with post-parse rewrite rules (which is also
what Haskell does iirc), in fact, you could implement these rules via a macro.
But I don't like it and I don't see why we would need it.
I think the user should know there is a conflicting implementation of the same
proc, and has to explicitly define which import he means to use. that is, from
x import op`+` or possibly the full proc signature if operators with the same
name are allowed.
I read somewhere in the forums that someone once suggested to add overridable
operator precedence to the compiler, and it seemed that Araq had flat out
refused. I think there are several good reasons to not allow this, the most
important for me being: it's hard to understand code that
I read somewhere in the forums that someone once suggested to add overridable
operator precedence to the compiler, and it seemed that Araq had flat out
refused. I think there are several good reasons to not allow this, the most
important for me being: it's hard to understand code that
10 matches
Mail list logo
