Operator Overloading

answered Mar 07

Hossein
81 ● 8 ● 20

When I read this answer a few months ago, I thought: "OK, reasonable. Not very comfortable to me. But, I need to get on with it...". It turns out though that the lack of user-defined operator overloading caused a bug in my Rascal development that took my past two complete days to hunt down. As an experienced industrial programmer, I myself had never experimented such a thing. I could never even think that this might ever happen. However, despite the very hard time I have had with it over two past days, I don't expect Rascal development team to rush on adding support for it ASAP. I'm simply sharing an experience of mine that is relevant to this thread.

I have a piece of code which used to use domainX somewhere. It had come to my notice that this code causes stack overflow due to infinite recursion. After having some debugging, I realised that this is due to the fact that domainX doesn't do what it's supposed to. As a result, the map on which operation runs never shrinks and the computation never ends. I came to know that the reason why this happens is that domainX uses the built-in operator == for exclusion -- which happens not to have the correct semantics for my ADT. Given that Rascal doesn't support user-defined operator overloading, I had to implement my own version of domainX manually. World would have been much nicer if I could simply get this correctness by adding my own operator == overload...

Now, whilst understanding your concerns for not adding this feature, I would like to say that there is a third way too: Rascal can provide another overload of domainX which takes predicates! :)