5 ms·

I think operator overloading should be fine even for puritans, as long the language requires the type to be numerical in a strict sense, and so they have a well

I think operator overloading should be fine even for puritans, as long the language requires the type to be numerical in a strict sense, and so they have a well defined semantics. So integers, floating point, complex numbers, vectors, matrices, etc.

justinpombrio 3y ago
How would the language require it to be numerical? For example, if you're defining complex numbers in a library, what would the compiler be checking about your ComplexNumber type before allowing you to define `+` for it?
- naasking 3y ago
  A few ways. The compiler could enforce commutativity, associativity and other properties of those operators. Another possible route is to require that all types contained within the exported types are also numerical, or have some specific set of operators defined.
  - SkiFire13 3y ago
    Do you mean at the type level or also for the operational semantics? In the latter case it's undecidable. Also, you mentioned matrices in the previous comment, but multiplication between matrices is not commutative.
    - naasking 3y ago
      It's undecidable if the language used to define operators is sufficiently expressive. Even simple syntactic constraints would work well enough for most scenarios, like "operators may only be defined by an expression containing other operators". New types also don't have to inherit the properties of the operators they use. In any case, my point was that there are multiple avenues to explore in providing operators in a way that don't compromise the compiler's ability to optimize numerical code.
throwawaymaths 3y ago
The problem with operator overloading is not really numericity, IMO. The problems are: - hidden control flow (function calls should look like function calls, an operation should never mask a function call) - global weirdness. If a library changes the language, how does that affect some other code you're pulling in? Where do you effect those changes?
- spc476 3y ago
  Some CPUs don't have a MUL or (like some 32-bit RISC architectures) DIV instruction, and on these, the C compile has to fall back to a function call.
  - throwawaymaths 3y ago
    You sure the compiler doesn't inline it? That an operator might take more than one opcode I think is uncontroversial
    - kps 3y ago
      Multiplication takes more than a handful of instructions if the hardware doesn't do it. https://godbolt.org/z/ccYPaz1Pj https://godbolt.org/z/ccYPaz1Pj For this example (AVR), this is the int multiply function __mulhi3: 00: 00 24 eor r0, r0 02: 55 27 eor r21, r21 04: 00 c0 rjmp .+0 06: 08 0e add r0, r24 08: 59 1f adc r21, r25 0a: 88 0f add r24, r24 0c: 99 1f adc r25, r25 0e: 00 97 sbiw r24, 0x00 10: 01 f0 breq .+0 12: 76 95 lsr r23 14: 67 95 ror r22 16: 00 f0 brcs .+0 18: 71 05 cpc r23, r1 1a: 01 f4 brne .+0 1c: 80 2d mov r24, r0 1e: 95 2f mov r25, r21 20: 08 95 ret
      - throwawaymaths 3y ago
        I mean, pedantically speaking the normal zig operators do control flow in their operators, in checked mode they panic on overflow, etc (you're not supposed to recover from them but I suppose it's possible). There's probably (internal) control flow in the saturating operators, etc.

justinpombrio 3y ago

How would the language require it to be numerical? For example, if you're defining complex numbers in a library, what would the compiler be checking about your ComplexNumber type before allowing you to define `+` for it?

naasking 3y ago
A few ways. The compiler could enforce commutativity, associativity and other properties of those operators. Another possible route is to require that all types contained within the exported types are also numerical, or have some specific set of operators defined.
- SkiFire13 3y ago
  Do you mean at the type level or also for the operational semantics? In the latter case it's undecidable. Also, you mentioned matrices in the previous comment, but multiplication between matrices is not commutative.
  - naasking 3y ago
    It's undecidable if the language used to define operators is sufficiently expressive. Even simple syntactic constraints would work well enough for most scenarios, like "operators may only be defined by an expression containing other operators". New types also don't have to inherit the properties of the operators they use. In any case, my point was that there are multiple avenues to explore in providing operators in a way that don't compromise the compiler's ability to optimize numerical code.

throwawaymaths 3y ago

The problem with operator overloading is not really numericity, IMO. The problems are: - hidden control flow (function calls should look like function calls, an operation should never mask a function call) - global weirdness. If a library changes the language, how does that affect some other code you're pulling in? Where do you effect those changes?

spc476 3y ago
Some CPUs don't have a MUL or (like some 32-bit RISC architectures) DIV instruction, and on these, the C compile has to fall back to a function call.
- throwawaymaths 3y ago
  You sure the compiler doesn't inline it? That an operator might take more than one opcode I think is uncontroversial
  - kps 3y ago
    Multiplication takes more than a handful of instructions if the hardware doesn't do it. https://godbolt.org/z/ccYPaz1Pj https://godbolt.org/z/ccYPaz1Pj For this example (AVR), this is the int multiply function __mulhi3: 00: 00 24 eor r0, r0 02: 55 27 eor r21, r21 04: 00 c0 rjmp .+0 06: 08 0e add r0, r24 08: 59 1f adc r21, r25 0a: 88 0f add r24, r24 0c: 99 1f adc r25, r25 0e: 00 97 sbiw r24, 0x00 10: 01 f0 breq .+0 12: 76 95 lsr r23 14: 67 95 ror r22 16: 00 f0 brcs .+0 18: 71 05 cpc r23, r1 1a: 01 f4 brne .+0 1c: 80 2d mov r24, r0 1e: 95 2f mov r25, r21 20: 08 95 ret
    - throwawaymaths 3y ago
      I mean, pedantically speaking the normal zig operators do control flow in their operators, in checked mode they panic on overflow, etc (you're not supposed to recover from them but I suppose it's possible). There's probably (internal) control flow in the saturating operators, etc.