Michiel wrote:
>>>It would just be good if there was a standard and universally recognizable way to
>>>do it.
>>>
>>>A standard abstract class for message-sending that you can subclass. With standard
>>>subclasses for std-out, std-err, std-in, file-out and file-in.
>>
>>Have you looked at Tango's IO classes?  I think Tango has that pretty
>>much.
> 
> 
> I had actually not. :)
> 
> I'll look into that, thanks. I still think it deserves to be in the standard
> library, though.

that's what Tango is trying to be, *the* standard library.

Hasan Aljudy wrote:
> That's because you're a nerd, Walter <g>

Yup <g>.

> I learned C++ I/O long long before I learned bit manipulation and bit shifting.
> 
> In fact, I was kinda surprised when I learned that C uses << as a bit shifting operator.
> 
>> Now back to '<<' and '>>'. To me, they are arithmetic operators, and mean shift left and shift right. Shift is not an I/O operation. To say they are intuitive is not because they are, but because C++ users are simply accustomed to it.
> 
> Same goes for using them as bit shifting, to say it scream bit shifting is not because it does, but because you are accustomed to it.

Every other "C like" language uses << for shifting.

Manfred Nowak wrote:
> The degree sign does not require unicode; it is in the normal ISO/IEC 8859-1 or latin1 table.

All characters above 0x7F require unicode multibyte encodings. The latin1 table is not an encoding subset of unicode.

Walter Bright wrote

> All characters above 0x7F require unicode multibyte encodings. The latin1 table is not an encoding subset of unicode.

This invalidates the proposed character only, which is of minor importance.

-manfred

Manfred Nowak wrote:
> Walter Bright wrote
> 
>> All characters above 0x7F require unicode multibyte encodings. The
>> latin1 table is not an encoding subset of unicode.
> 
> This invalidates the proposed character only, which is of minor importance.

There isn't much left below 0x7F :-(

Walter Bright wrote:
> Manfred Nowak wrote:
> 
>> Walter Bright wrote
>>
>>> All characters above 0x7F require unicode multibyte encodings. The
>>> latin1 table is not an encoding subset of unicode.
>>
>>
>> This invalidates the proposed character only, which is of minor importance.
> 
> 
> There isn't much left below 0x7F :-(

Hmmmm, abstract algebra...
would this be easily parsable?
other objections?
a = b (+) c;
a = b (-) c;
a = b (*) c;
a = b (^) c;
a = b (|) c;
a = b ($) c;
a = b (?) c;
etc...

That first one kinda reminds me of the everyone's favorite circle-with-plus-inside.

Chad J wrote:
> Hmmmm, abstract algebra...
> would this be easily parsable?
> other objections?
> a = b (+) c;
> a = b (-) c;
> a = b (*) c;
> a = b (^) c;
> a = b (|) c;
> a = b ($) c;
> a = b (?) c;
> etc...

Yes.

Walter Bright wrote:
> Chad J wrote:
>> Hmmmm, abstract algebra...
>> would this be easily parsable?
>> other objections?
>> a = b (+) c;
>> a = b (-) c;
>> a = b (*) c;
>> a = b (^) c;
>> a = b (|) c;
>> a = b ($) c;
>> a = b (?) c;
>> etc...
> 
> Yes.

You mean yes on both counts?

It's kind of a controversial thing, I know, but for some types there really are multiple ways to interpret basic operations.  Matlab, for example, defines .* to mean element-wise multiplication and * to mean matrix multiplication.  Both forms get plenty of use.  (Same for exponentiation too -- .^ and ^ both exist).

I don't really care either way, but there is at least one example of a widely used language, specifically for math, in which there are more than the standard set of operators.

Also Ocaml or Haskell or one of those guys, I forget which, allows definition of new operators using any combination of characters used in the built-in operators.  E.g.  **+ or */* or +++ or +- can all be made into custom operators.  I have to admit, /That/ one seems like a pretty bad idea to me.  :-)

--bb

Bill Baxter wrote:
> Walter Bright wrote:
>> Chad J wrote:
>>> Hmmmm, abstract algebra...
>>> would this be easily parsable?
>>> other objections?
>>> a = b (+) c;
>>> a = b (-) c;
>>> a = b (*) c;
>>> a = b (^) c;
>>> a = b (|) c;
>>> a = b ($) c;
>>> a = b (?) c;
>>> etc...
>>
>> Yes.
> 
> You mean yes on both counts?
> 
> It's kind of a controversial thing, I know, but for some types there really are multiple ways to interpret basic operations.  Matlab, for example, defines .* to mean element-wise multiplication and * to mean matrix multiplication.  Both forms get plenty of use.  (Same for exponentiation too -- .^ and ^ both exist).
> 
> I don't really care either way, but there is at least one example of a widely used language, specifically for math, in which there are more than the standard set of operators.
> 
> Also Ocaml or Haskell or one of those guys, I forget which, allows definition of new operators using any combination of characters used in the built-in operators.  E.g.  **+ or */* or +++ or +- can all be made into custom operators.  I have to admit, /That/ one seems like a pretty bad idea to me.  :-)

Cecil too. Didn't have a problem with it.

http://compilers.iecc.com/comparch/article/96-12-127


Andrei

Walter Bright wrote:
> Michiel wrote:
>  >> And we should keep on frowning on attempts to use overloaded << for I/O
>  >> purposes <g>.
>  >
>  > Why? I think it's intuitive. The arrows point from the source of the message to
>  > the destination. Should the operator only be used for shifting because that
>  > happens to have been its first purpose?
>  >
>  > I also like how you can send a message to an abstract object. And that can be a
>  > cout, a cerr, an error console in a GUI, or something else. Same thing the other
>  > way around.
> 
> Good question. C++ conventional wisdom is that's great, because it's always been done that way in C++. Few question it.
> 
> Let's step back a bit. Suppose I overload '+' to be "launch nuclear missiles." You see some code:
> 
>     x = a + b;
> 
> and what do you think? I think "add a and b, assign the result to x", but instead, nuclear missiles are launched. It is completely unexpected and unintuitive for '+' to mean anything other than 'add'. To do something completely unrelated to 'add', one should instead write:
> 
>     x = launchNuclearMissiles(a, b);
> 
> where the meaning is plain, or at least, one isn't assuming it's adding a and b.
> 
> So why overload operators at all? For the purposes of implementing UDTs (User Defined Types) that have legitimate arithmetic operations on them, such as matrices, extended precision numbers, etc.
> 
> Now back to '<<' and '>>'. To me, they are arithmetic operators, and mean shift left and shift right. Shift is not an I/O operation. To say they are intuitive is not because they are, but because C++ users are simply accustomed to it.
> 
>     a << b << c << d;
> 
> That doesn't scream I/O to me. 

I agree. There's another problem -- it really doesn't scale well. With printf, you can do "%3.5f" to print a floating point number with a given precision. With <<, that same operation is really horrible.

I'd like to see a couple more clarifications in the spec, wrt operator overloading:
* If both opAddAssign and opAdd are provided, the compiler is permitted to replace expressions of the form a = a+b; with a+=b; (that is, a+=b _must_ mean a=a+b). And similarly for the other operators.

It's just insanity to make a+=b mean anything other that a = a + b.
Incidentally, this would make my 'operator overloading without temporaries' proposal a non-breaking change.



And if a, b, etc. are non-trivial
> expressions, they wind up:
> 
> 1) interacting with the operator precedence of << in unfortunate ways
> 
> 2) suppose you want to print a variable shifted left by a few bits:
> 
>     a << (b << 3) << c << d;
> 
> blech.
> 
> 3) Suppose you've got some relational operators and templates thrown in:
> 
>     a << b<c<3>> << c < d << e;
> 
> and things just go downhill from there.
> 
> 4) Operators aren't very greppable, meaning it's hard to go grepping through source code looking to see if << has been overloaded.
> 
> 5) The Spirit library for C++ uses operator overloading to create a specialized DSL for specifying grammar. The trouble is, the code looks exactly like regular C++ expressions (since new operators cannot be defined, nor can operator precedence be changed), and there are some big warning boxes that the resulting appearance may LOOK like C++ but is about as far removed from it as one can get. This doesn't enhance readability.
> 
> And to sum up:
> 
>     writefln(a, b, c, d);
> 
> seems pretty intuitive to me. There's just no advantage to overloading <<.