Walter Bright wrote

> I disagree, because this is in the context of computer programming, not abstract algebra. C++ stands out alone in its use of << for such, and is therefore unconventional.

I do not understand with what you disagree.

However, I agree with you, that the semantics of << in C++ distorts at least my thinking as much as 1- x in the semantics of lisp.

I understand your wish to have fixed meanings for several operators. But I do not understand that D does not provide similar operators for free usage.

"+", "-" and all the others with fixed meaning could be prefixed for example by the degree symbol "°+", "°-" and provided with the same priorities as their unprefixed counter parts.

Thus enabling a possibly interwoven parallel expression hierarchy.

-manfred

> > 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.

> But I do not understand that D does not provide similar operators for free usage.

I would like that. Just some extra operators that you can use for your personalized types.

I'm not sure if I like the prefix-idea, though. An operator should be intuitive (readable) and easy to use. A prefix pretty much removes that advantage, and I would rather use functions. (By the way, I think the operator-symbols should at least be on a standard keyboard.)

But ->, <-, postfix !, !in, etc. would be good.

Manfred Nowak wrote:
> I understand your wish to have fixed meanings for several operators. But I do not understand that D does not provide similar operators for free usage.
> 
> "+", "-" and all the others with fixed meaning could be prefixed for example by the degree symbol "°+", "°-" and provided with the same priorities as their unprefixed counter parts.
> 
> Thus enabling a possibly interwoven parallel expression hierarchy.

The problem with using unicode operators is that unicode isn't as well supported as it should be. It's one thing to support unicode in the language, it's another to require one to use a unicode capable text editor to edit source code.

On Wed, 14 Feb 2007 14:45:50 -0800, Walter Bright wrote:

> Michiel wrote:
>> To sum up: I love D. But I also like the streaming operator.
> 
> I didn't expect to convince you <g>.

Moving away from the idea of *overloading* existing operators, is there any case for new operators that implement I/O?

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
15/02/2007 11:36:07 AM

Walter Bright wrote

> The problem with using unicode operators is that unicode isn't as well supported as it should be. It's one thing to support unicode in the language, it's another to require one to use a unicode capable text editor to edit source code.

The degree sign does not require unicode; it is in the normal ISO/IEC 8859-1 or latin1 table. Every editor should be capable to display it. Every system should be able to enter it.

The degree sign "°" is under windows reachable via <alt>0176.

The masculine ordinal indicator "º" via <alt>0186.

The currency sign "¤" via <alt>0164.

So: there is no such problem.

-manfred

That's because you're a nerd, Walter <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.


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. 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 <<.

Michiel wrote

> An operator should
> be intuitive (readable) and easy to use. A prefix pretty much
> removes that advantage, and I would rather use functions. (By the
> way, I think the operator-symbols should at least be on a standard
> keyboard.)
> 
> But ->, <-, postfix !, !in, etc. would be good.

New operators are not intuitiv either, because one has to learn their priorities---or one will end up with fully parenthesed expressions.

Whether a prefix or a postfix and what characters will be choosen are of minor importance. I referred to the degree sign, because it is on the german standard keyboard and reminds at the often used middle circle in abstract algebras.

-manfred

On Thu, 15 Feb 2007 01:53:47 +0000 (UTC), Manfred Nowak wrote:

> Walter Bright wrote
> 
>> The problem with using unicode operators is that unicode isn't as well supported as it should be. It's one thing to support unicode in the language, it's another to require one to use a unicode capable text editor to edit source code.
> 
> The degree sign does not require unicode; it is in the normal ISO/IEC 8859-1 or latin1 table. Every editor should be capable to display it. Every system should be able to enter it.

LOL ... just because something *should* doesn't mean that it *will*.

> The degree sign "°" is under windows reachable via <alt>0176.
> 
> The masculine ordinal indicator "º" via <alt>0186.
> 
> The currency sign "¤" via <alt>0164.
> 
> So: there is no such problem.

The editors I use all trap keystrokes and none of them allow 'raw' alt-xxx entry of characters. So: there is such a problem. <G>

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
15/02/2007 1:15:44 PM

Derek Parnell wrote:
> On Wed, 14 Feb 2007 14:45:50 -0800, Walter Bright wrote:
> 
>> Michiel wrote:
>>> To sum up: I love D. But I also like the streaming operator.
>> I didn't expect to convince you <g>.
> 
> Moving away from the idea of *overloading* existing operators, is there any
> case for new operators that implement I/O?

Imho the only serious reason for overloading << in C++ for I/O was the lack of decent variadic functions.

Andrei