Operator precedence: Difference between revisions
Content deleted Content added
→{{header|BQN}}: Add precedence table |
→{{header|Phix}}: added a paragraph for parameter passing, which I'd missed. |
||
| Line 1,979: | Line 1,979: | ||
Perhaps surprisingly Phix does not rely on associativity, mainly because it has a power() function rather than an infix operator for that.<br> You could alternatively say that all the above operators bar the unary ops are left associative, within their own precedence level. |
Perhaps surprisingly Phix does not rely on associativity, mainly because it has a power() function rather than an infix operator for that.<br> You could alternatively say that all the above operators bar the unary ops are left associative, within their own precedence level. |
||
Phix has reference counting with copy-on-write semantics: technically parameters are always passed by reference, which can improve performance, however attempting to modify anything with a reference count greater than one performs an internal clone (at that level) which means it ''behaves'' as if everything were being passed by value.<br> |
|||
It also has automatic pass by reference for local variables such that (eg) <code>table = somefunc(table)</code> does ''not'' increase the reference count (in practice the calling code's local variable becomes unassigned over the call) and consequently makes in-situ modification possible, which can obviously also significantly benefit performance.<br> |
|||
Under "with js", aka "with javascript_semantics", any said internal clone triggers a runtime error, effectively prohibiting copy-on-write semantics and thus ensuring the code is compatible with JavaScript, and in fact also implicitly banning the usual pass-by-sharing semantics of JavaScript, except where covered by the automatic pbr handling. |
|||
=={{header|PHP}}== |
=={{header|PHP}}== |
||