[SOLVED] DSRN (dog slow roman numerals)

[Claudio L.]

(06-15-2014 07:29 PM)Thomas Klemm Wrote:  

(06-15-2014 06:48 PM)Claudio L. Wrote:  What would be a down side in your opinion?

I have a problem with overloading + for operations that violate basic rules of addition.
In the case of string concatenation it is the commutative property: "a" + "b" ≠ "b" + "a"
For this operation another symbol should be used: . or ~ or ++ or whatever.

It's the same with concatenating lists. But it gets worse with the "addition" of an element to a list.
Why is { 1 2 3 } + 4 = { 1 2 3 4 } but { 5 6 7 } - 4 = { 1 2 3 }?
But then 4 + { 1 2 3 } = { 5 6 7 }.
And if you really want to add a number to each element you have to use ADD: { 1 2 3 } ADD 4 = { 5 6 7 }
I still think this was the worst decision when designing RPL.

Cheers
Thomas

We are on the same page, here. But that's not a downside of overloading operators, it's just a bad choice! newRPL already has the '+' operator working on lists by adding element by element. The ADD command will concatenate lists.
And for what is worth, I don't have a problem with making '+' fail for strings and have ADD or CONCAT, etc. to concatenate strings.

That's actually the beauty of overloading operators, you can make them do whatever you want.

Actually, thanks to "proper" overloading of the '+' operators for lists, doing things like MAP, with nested lists is a breeze, just apply the same '+' operator recursively to all elements, whether they are lists or not. It's already done and working fine. The resulting code is surprisingly clean, so I was wondering what the downsides are (I'm still wondering).

Claudio