<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">It's ironic that you mention C++, because C++ is *the* example of</div><div class="gmail_default" style="font-family:monospace,monospace">operator abuse. I mean, *really*, using "<<" for both left shift</div><div class="gmail_default" style="font-family:monospace,monospace">and output? That's almost as evil as using "+" for string concatenation.</div><div class="gmail_default" style="font-family:monospace,monospace">The problem with C++ is that it allows completely ad hoc overloading</div><div class="gmail_default" style="font-family:monospace,monospace">BUT does not allow operator *introduction* so that there is enormous</div><div class="gmail_default" style="font-family:monospace,monospace">pressure on the same few operators that happen to be built in.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">The example of X^Y is an interesting one, because you don't, you really</div><div class="gmail_default" style="font-family:monospace,monospace">don't, want to go around writing exp(Y*log(X)) all the time. Not only</div><div class="gmail_default" style="font-family:monospace,monospace">does it involve three operations, when only one is intended, but in</div><div class="gmail_default" style="font-family:monospace,monospace">many cases they are the *wrong* operations. (Notably, but not only,</div><div class="gmail_default" style="font-family:monospace,monospace">when Y is an integer.) The other thing is the notation itself. There</div><div class="gmail_default" style="font-family:monospace,monospace">is no such operator in high-school maths. And the reason ^ is used is</div><div class="gmail_default" style="font-family:monospace,monospace">that in ASCII-63 (as implemented on the Model 33 teletype, for one</div><div class="gmail_default" style="font-family:monospace,monospace">popular example), that codepoint was used for ↑ so people were actually</div><div class="gmail_default" style="font-family:monospace,monospace">writing X↑Y. ASCII-67 replaced ↑ with ^. And there were two operators</div><div class="gmail_default" style="font-family:monospace,monospace">ASCII meant to give us that we seldom get. The \ character was added</div><div class="gmail_default" style="font-family:monospace,monospace">to ASCII for the specific purpose of letting you write /\ (and, min,</div><div class="gmail_default" style="font-family:monospace,monospace">meet) and \/ (or, max, join). How many programming languages let you</div><div class="gmail_default" style="font-family:monospace,monospace">use _those_ very well established operators?</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">There are many things that might reasonably be taken as infix</div><div class="gmail_default" style="font-family:monospace,monospace">operators:</div><div class="gmail_default" style="font-family:monospace,monospace"> List includes Element</div><div class="gmail_default" style="font-family:monospace,monospace"> Long begins_with Short</div><div class="gmail_default" style="font-family:monospace,monospace"> X <=> Y -- increasingly popular 3-way comparison</div><div class="gmail_default" style="font-family:monospace,monospace">(these examples were chosen to be at the same level as >=)</div><div class="gmail_default" style="font-family:monospace,monospace"> Mat1 %*% Mat2 -- matrix multiplication in R</div><div class="gmail_default" style="font-family:monospace,monospace"> Set1 union: Set2 -- set operation in Smalltalk</div><div class="gmail_default" style="font-family:monospace,monospace">and of course assorted parser combinators and other combinators.</div><div class="gmail_default" style="font-family:monospace,monospace">I count 28 operators in SML. (Proper handling of IEEE comparison</div><div class="gmail_default" style="font-family:monospace,monospace">needs more than six "relational operators", and SML has some but</div><div class="gmail_default" style="font-family:monospace,monospace">not all of the extras.)</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Here's an interesting question.</div><div class="gmail_default" style="font-family:monospace,monospace">The designers of Ada thought that letting people mix up 'and' and 'or'</div><div class="gmail_default" style="font-family:monospace,monospace">without parentheses was dangerous. So you can have</div><div class="gmail_default" style="font-family:monospace,monospace"> e0 and e1 and ... and en</div><div class="gmail_default" style="font-family:monospace,monospace">and you can have</div><div class="gmail_default" style="font-family:monospace,monospace"> e0 or e1 or ... or en</div><div class="gmail_default" style="font-family:monospace,monospace">but you cannot have</div><div class="gmail_default" style="font-family:monospace,monospace"> e0 and e1 or e2</div><div class="gmail_default" style="font-family:monospace,monospace">So are 'and' and 'or' operators in Ada, or should they be thought of as</div><div class="gmail_default" style="font-family:monospace,monospace">special multi-operator forms? If the latter, how would you declare such things?</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">My own impression, and it is no more than that,</div><div class="gmail_default" style="font-family:monospace,monospace">is that infix operators help a lot when you are treating something</div><div class="gmail_default" style="font-family:monospace,monospace">as a quasi-algebraic expression that you are interested in rearranging</div><div class="gmail_default" style="font-family:monospace,monospace">and simplifying in a mathematical way. I don't think it is a coincidence</div><div class="gmail_default" style="font-family:monospace,monospace">that the Bird-Meertens approach does that, and that specification languages</div><div class="gmail_default" style="font-family:monospace,monospace">often have lots of operators. In particular, when you are transforming</div><div class="gmail_default" style="font-family:monospace,monospace">expressions by hand, you can tolerate a fair bit of precedence fuzziness</div><div class="gmail_default" style="font-family:monospace,monospace">and even outright ambiguity.</div><div class="gmail_default" style="font-family:monospace,monospace">On the other hand, bulkier, clunkier, but more obvious syntax seems to</div><div class="gmail_default" style="font-family:monospace,monospace">work better for code that you want other people to read.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Just an impression, for what it is worth.</div></div></div></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div></div>