<div class="gmail_quote">On 1 December 2010 14:49, Jay K <span dir="ltr"><<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>></span> wrote:<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div> >  <b>not</b> proper in terms of semantics (<font face="'courier new', monospace">operator<<</font> and <font face="'courier new', monospace">operator>></font> being obvious cases)<br>
</div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div>This would not be allowed in my constrained proposal.</div></div></blockquote>
<div><br></div><div>How would you stop it?  How would you enforce a rule that says "<<" means that you are somehow shifting something to the left, even if the representation isn't a binary integer?  How would you enforce a rule that says "+" must add, not concatenate, subtract, multiply or reset the computer?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div><div class="im">> but also <font face="'courier new', monospace">operator+</font> for concatenation<br>
</div></div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div><div class="im"></div>This is very reasonable.</div></div></blockquote>
<div><br></div><div>No, it is not.  The semantics of concatenation are hugely different from the semantics of addition.  Consider 3+4 vs. 4+3.  Now consider "three"+"four" vs. "four"+"three".  If you want to do concatenation, have an operator for concatenation.  (++, say, as a random example.)  Do not overload addition with an operation that isn't even vaguely analogous.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div><div class="im"> > utterly painful uses for <font face="'courier new', monospace">operator,</font>)<br>
</div></div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div><div class="im">I'm surprised that is overloadable, but indeed it appears it is. I don't think I have *ever* seen anyone overload it, and I have seen a lot.</div>
</div></div></blockquote><div><br></div><div>I would tell you how I used it, but I'm utterly ashamed of that portion of my life.  ;)  (It was in a type-safe SQL query builder.)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div><div class="im"> > the inability to define <b>new</b> operators (which leads to the first problem of idiots redefining the semantics of operators)<br></div></div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div><div class="im">Stroupstroup rejected this as too complex. (See the Design&Evolution book).</div></div></div></blockquote><div><br></div><div>Stroustrup is, not to put too fine a point on this, a gibbering lunatic.  He rejected defining new operators as "too complex" -- yet created a language that to this day is nigh-impossible to implement according to specification (a situation that will be made even worse with the never-arriving C++1x).  In the meantime languages far simpler than C++ (syntactically, at least) have had the ability to define new operators at will for ages.  Haskell, for example, as a top of my head instance.  Prolog too, if memory serves.</div>
<div><br></div><div>Personally, I'd much rather try to implement a parser for Haskell or Prolog or languages in that vein than I would a C++ parser.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div>I don't see people pine for this often and I suspect he did the right thing.<br></div></div></blockquote><div><br></div><div>People don't pine for it often because people don't pine for capabilities they don't know exist.  Most people don't pine for hygenic macro systems either -- until they use them in languages that provide that kind of capability.  People didn't pine for RTTI in C++ either ... until it became available in some compilers and other compilers seemed far more constrained.  People didn't pine for automated memory management ... until Java came along and made it mainstream.  People didn't pine for multi-threading ... until everybody and their dog supported it.  Hell, people didn't pine, by and large, for <b>operator overloading </b>until C++ made it mainstream!</div>
<div><br></div><div>What people pine for vs. what people need or at least can truly use are such radically disjoint sets that I often use what people pine for as a hint for what to <b>avoid</b>.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div>It creates a layering problem I believe in the typical structure.<br>The lexical analysis would have to get information from higher layers.</div></div></blockquote><div><br></div><div>Or you could go the Haskell route.  Any token that consists of purely "special symbols" is an operator that can be used directly as an operator.  To use it as a regular function you need to wrap it in parens.  This means I can define, say, a "UFO operator" like <=+=+=+=> (made deliberately gonzo for fun) and use it as-is--e.g.: Expr1 <=+=+=+=> Expr2--or as a two-parameter function call--(<=+=+=+=>) Expr1 Expr2.  Further you can go more down the Haskell route and make any function usable as an operator: myFunc Expr1 Expr2 is equally usable as Expr1 `myFunc` Expr2.</div>
<div><br></div><div>Can you see how lexical analysis can trivially identify your operator definitions and usage here?</div><meta http-equiv="content-type" content="text/html; charset=utf-8"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div><div class="im"> > unexpected costs to operations making the eyeballing of execution complexity (time-wise and memory-wise) literally impossible<br>
</div></div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div><div class="im">This is already the case. As I said. So let's say that every single function call is shown. It is hard to know which functions have which cost.</div>
There are also hidden function calls e.g. for "try" and every pointer derereference (right?)<br></div></div></blockquote><div><br></div><div>Operator overloading can multiply these by orders of magnitude and have the added problem of being, in effect, "COME FROM" statements.  I mean they're not as bad in this regard as, say, Aspect-Oriented Programming, but they're still pretty nasty.  The fact that features X and Y have hidden costs is not really a good argument for adding feature Z that has all those hidden costs and an order of magnitude more all concealed in such a way that it is almost impossible to keep track of where things are really going.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div>Please consider floating point. Historically floating point was "soft float". Sometimes these days it still us. Yet we still have operators for floating point.<br>
Why? Because it is just so convenient and idiomatic. Why stop there?<br></div></div></blockquote><div><br></div><div>Because at some point the costs outweigh the benefits.  Operator overloading is at just that cusp point for me to be torn.  It has some major benefits, but it has major costs and right now I actually lean slightly in the direction of thinking the costs outweigh the benefits.  (A few years ago I leaned slightly in the other direction, mind, so it, as a feature is not something I'm going to reject a language for.)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div>A primary design point of C++ is to give user defined types all the powers of built in types.<br>
</div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div>No longer does it require a compiler change to introduce a type with the "power" of int. And so on.</div>
</div></blockquote><div><br></div><div>Instead it allows you to introduce a type that looks like an int but has such wildly varying semantics that it will confuse the ever living daylights out of people using it.  Like using "+" for concatenation.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div><div class="im">> painful interaction with templates that makes a perfect storm of eye-damaging syntax</div>
</div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>Huh? Specifically?<br></div></blockquote><div><br></div><div>My C++ days are a decade behind me so I no longer have any source that illustrates this.  I just recall that any time we had a templated class with overloaded operators that it turned into an asinine stew of unreadable code.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>The one vague reason I don't fully understand is: C doesn't have it.<br>Does C represent a good example of a sort of minimalism? Maybe.<br>
It isn't clear to me the value of C. It has been *very* widely abandoned in favor of C++.<br></div></blockquote><div><br></div><div>What is the FFI lingua franca again?  C or C++?  (Hint: one of those two languages has syntax to make it compatible with the other, but not vice versa.)</div>
<div><br></div></div>-- <br>"Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot."<br>
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.<br>