4 ms·

That's just a "type system by obscurity". Extending it to provide the same sort safety, you'd need specific function for all combinations of types: sum_two_inte

That's just a "type system by obscurity". Extending it to provide the same sort safety, you'd need specific function for all combinations of types: sum_two_integers(), sum_integer_and_float() etc... Which would be both extremely ugly and a terrible waste of memory.

thaumasiotes 9y ago
You seem to have missed the whole point of my comment. sum_integer_and_float() is the opposite of what I'm talking about. If you wanted to extend this system within numeric operations, you'd have e.g. divide_and_return_integer() vs divide_and_return_float() (funnily enough, this is also a very popular distinction for languages to draw); sum_and_return_integer() vs sum_and_return_float(); etc. This usually isn't done because integers and decimals are fundamentally very similar, so for addition there is a platonic correct result when you add an integer and a float (the floating point result), and the operation returns that. Then, if you wanted an int, you can cast your result. That doesn't work if you want to consider string concatenation to be a form of numeric addition. It isn't. There is no ideal result when adding a string to a number, and if you do one when you meant to do the other, there is no way of producing the data you wanted ("11") from the data you have (2). Perl doesn't have much of a type system. But it solves the common problem of manipulating strings when you meant to manipulate numbers, or vice versa, by not assigning the same operators to these radically different operations, and I think that was the correct choice, even for languages with stricter type systems.
- thaumasiotes 9y ago
  > This usually isn't done because integers and decimals are fundamentally very similar, so for addition there is a platonic correct result when you add an integer and a float (the floating point result) After further consideration, I believe this is incorrect. This usually isn't done because integers are closed under addition, subtraction, and multiplication, so the "promote according to argument type" C behavior doesn't lose accuracy in those cases. There obviously is a platonic correct result when you divide two integers, but it is not in general an integer, so the C behavior introduces bugs (explaining the popularity of divide_and_return_float() -- I don't care what types the arguments were, as long as I get the result I'm looking for).

thaumasiotes 9y ago

You seem to have missed the whole point of my comment. sum_integer_and_float() is the opposite of what I'm talking about. If you wanted to extend this system within numeric operations, you'd have e.g. divide_and_return_integer() vs divide_and_return_float() (funnily enough, this is also a very popular distinction for languages to draw); sum_and_return_integer() vs sum_and_return_float(); etc. This usually isn't done because integers and decimals are fundamentally very similar, so for addition there is a platonic correct result when you add an integer and a float (the floating point result), and the operation returns that. Then, if you wanted an int, you can cast your result. That doesn't work if you want to consider string concatenation to be a form of numeric addition. It isn't. There is no ideal result when adding a string to a number, and if you do one when you meant to do the other, there is no way of producing the data you wanted ("11") from the data you have (2). Perl doesn't have much of a type system. But it solves the common problem of manipulating strings when you meant to manipulate numbers, or vice versa, by not assigning the same operators to these radically different operations, and I think that was the correct choice, even for languages with stricter type systems.

thaumasiotes 9y ago
> This usually isn't done because integers and decimals are fundamentally very similar, so for addition there is a platonic correct result when you add an integer and a float (the floating point result) After further consideration, I believe this is incorrect. This usually isn't done because integers are closed under addition, subtraction, and multiplication, so the "promote according to argument type" C behavior doesn't lose accuracy in those cases. There obviously is a platonic correct result when you divide two integers, but it is not in general an integer, so the C behavior introduces bugs (explaining the popularity of divide_and_return_float() -- I don't care what types the arguments were, as long as I get the result I'm looking for).