3 ms·

If you are discussing the semantic of the "integer + operator" then I have also completely another opinion: "it would not be the correct choice for default beh

by acqq 10y ago

If you are discussing the semantic of the "integer + operator" then I have also completely another opinion: "it would not be the correct choice for default behavior for the + operator in a language." No. Except if you're doing crypto, the wrap alone is never the desired mode. The wrap with the accessibility to the carry flag can be (just in implementing arithmetic with more bits). What the HL languages should actually do is not even allow the "easy" expressions in the integer domain, exactly because of all that. Moreover, missing accessibility of the carry flag in the HLL is also a problem. The instruction sets of ASM instructions are much more reasonable than the poor implementations of all the HL languages I know. "Exception on carry" instead of enforcing the code to be precise is the way to the many more accidents waiting to happen. The current practice of the HL languages is more of the lazy repetition of some old decision than the proper safety-preserving approach.

mikeash 10y ago
If you're arguing that there shouldn't be any default behavior, and the programmer should always be forced to choose, I could get behind that. I've also argued for degradation to bignums as the best default. This way the result is always correct. Of course, that means a performance hit on all arithmetic code unless you opt out of that, and you could make the case that this is also an unacceptable default. In any case, consider the "crashing is the best default choice" to be qualified with "if you're going to have some default choice for fixed-size integers."
- acqq 10y ago
  > I've also argued for degradation to bignums as the best default. It has sense for Python and Perl code but not for the code produced by something that would be better C than the current C. If the performance is critical (as to have to effectively no slowdown compared to what the CPU can achieve), the CPU machine code instructions already do "the right thing" and it's the HL languages that abstract the carry or the saturation away to make the wrong plain "+". C with the CPU-specific extensions can "do the right thing." It's the "standard" "language lawyers" that are once again wrong.

by acqq 10y ago

mikeash 10y ago

If you're arguing that there shouldn't be any default behavior, and the programmer should always be forced to choose, I could get behind that. I've also argued for degradation to bignums as the best default. This way the result is always correct. Of course, that means a performance hit on all arithmetic code unless you opt out of that, and you could make the case that this is also an unacceptable default. In any case, consider the "crashing is the best default choice" to be qualified with "if you're going to have some default choice for fixed-size integers."

acqq 10y ago
> I've also argued for degradation to bignums as the best default. It has sense for Python and Perl code but not for the code produced by something that would be better C than the current C. If the performance is critical (as to have to effectively no slowdown compared to what the CPU can achieve), the CPU machine code instructions already do "the right thing" and it's the HL languages that abstract the carry or the saturation away to make the wrong plain "+". C with the CPU-specific extensions can "do the right thing." It's the "standard" "language lawyers" that are once again wrong.