Andrei Alexandrescu (See Website For Email) wrote:
> kris wrote:
>> Walter clarified, a long time ago, that D would evaluate chained-calls from left to right. I suggest you ask Walter?
> 
> 
> As long as it's not in the language definition, you can't count on it. I think this is a language defect anyhow; I am lobbying Walter to define left-to-right order of evaluation in all cases.
> 
> Andrei

There are apparently a number of things that haven't made it into the "formal" language definition doc.

We've simply clarified such assertions, with Walter, along the way since there's only so much one person can do (and only so much whining one person will put up with). It would be great to have a completed language definition, but sometimes you have to accept a virtual handshake instead

== Quote from kris (foo@bar.com)'s article
> Frits van Bommel wrote:
> [snip]
> > What I'm trying to say here is basically this: you shouldn't rely on the order of evaluation of parameters. Not even if one of them happens to be used as 'this' for the method in question.
> Absolutely agree. Yet, without wishing to go off on a tangent, we're
> talking about call-chaining and not parameter evaluation-order. These
> are different things, and there was a painfully long thread on exactly
> this subject a year or two ago.
> Walter closed that one by stating call-chaining can only realistically
> evaluate from left to right (or something to that effect) and that's
> what D does.
> I'm sure JCC could locate that thread in a heartbeat ... don't know > how he
does that, but he sure is effective at it :)

These days, I Usually just use Google and restrict it to www.digitalmars.com (such as the search box on the Digital Mars webpage does).

I can't seem to track down this one though. My technique works best when I actually remember the particular post or discussion (and it works really well when I remember that I myself posted in the discussion). And I don't really remember this discussion.

Do you happen to remember who Walter was replying to? That could be helpful. I can't seem to find the right keywords to find the particular topic. I tried various combinations of "newshound" (Walter's e-mail), "evaluation", "order", "operator", "operation", "call", "chain", "return", "function", etc. Also, sometimes it's helpful if I know when the discussion took place (Last month? Last year? 2005?). But this might just be a needle that remains hidden in the haystack.

Perhaps we can just talk Walter into putting this principle in the D Specification. ;)

jcc7

jcc7 wrote:
> == Quote from kris (foo@bar.com)'s article
> 
>>Frits van Bommel wrote:
>>[snip]
>>
>>>What I'm trying to say here is basically this: you shouldn't rely on the
>>>order of evaluation of parameters. Not even if one of them happens to be
>>>used as 'this' for the method in question.
>>
>>Absolutely agree. Yet, without wishing to go off on a tangent, we're
>>talking about call-chaining and not parameter evaluation-order. These
>>are different things, and there was a painfully long thread on exactly
>>this subject a year or two ago.
>>Walter closed that one by stating call-chaining can only realistically
>>evaluate from left to right (or something to that effect) and that's
>>what D does.
>>I'm sure JCC could locate that thread in a heartbeat ... don't know > how he
> 
> does that, but he sure is effective at it :)
> 
> These days, I Usually just use Google and restrict it to www.digitalmars.com (such
> as the search box on the Digital Mars webpage does).
> 
> I can't seem to track down this one though. My technique works best when I
> actually remember the particular post or discussion (and it works really well when
> I remember that I myself posted in the discussion). And I don't really remember
> this discussion.
> 
> Do you happen to remember who Walter was replying to? That could be helpful. I
> can't seem to find the right keywords to find the particular topic. I tried
> various combinations of "newshound" (Walter's e-mail), "evaluation", "order",
> "operator", "operation", "call", "chain", "return", "function", etc. Also,
> sometimes it's helpful if I know when the discussion took place (Last month? Last
> year? 2005?). But this might just be a needle that remains hidden in the haystack.
> 
> Perhaps we can just talk Walter into putting this principle in the D Specification. ;)
> 
> jcc7

If I recall correctly, it started off as a complaint about the use of call-chaining in Mango, and resulted in someone leaving the NG for good (was his name manfred or something?)

Andrei Alexandrescu (See Website For Email) wrote:
> Sean Kelly wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>>> Sean Kelly wrote:
>>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>>> Bill Baxter wrote:
>>>>>>
>>>>>> I believe the current discussion is only about under-the-hood implementation issues.  So I don't think you have to worry about any D libraries exposing (good or bad) C/C++ design decisions to users.  Tango is going to expose the same D interface no matter how it's implemented under the hood.
>>>>>
>>>>> That's great, however the interface has a problem too: it does not produce atomic strings in multithreaded programs.
>>>>
>>>> Which interface?  And are you talking about input or output?
>>>
>>> Cout. The thing is that the design using the syntax Cout(a)(b) is conducive to two separate calls to the library. I recall this has been briefly discussed here.
>>
>> Just making sure we were on the same page.  In my experience, raw output is typically used for logging--that's about the only case I can think of where the random interleaving of messages is acceptable.  Tango has a separate logging facility which performs synchronization for exactly this purpose: tango.util.log.  Perhaps this particular critique would be more appropriately applied to the logging package?
> 
> I don't think so. For example, I have a multithreaded program that starts processes on multiple machines and outputs "stamped" lines to the standard output - lines with a prefix clarifying which machine the line comes from, and at what time. That output is gzipped for efficiency and transported via ethernet to a hub where the lines are demultiplexed and put into multiple files etc.
> 
> It is essential that lines are written atomically, but beyond that, the actual order does not matter.

This sounds to me like logging output, which is exactly what I described.  The logger could be attached to the console or a socket as easily as a file.  Why use Cout for this?


Sean

== Quote from kris (foo@bar.com)'s article
> jcc7 wrote:
> > == Quote from kris (foo@bar.com)'s article
> >
> >>Frits van Bommel wrote:
> >>[snip]
> >>
> >>>What I'm trying to say here is basically this: you shouldn't rely on the order of evaluation of parameters. Not even if one of them happens to be used as 'this' for the method in question.
> >>
> >>Absolutely agree. Yet, without wishing to go off on a tangent, we're
> >>talking about call-chaining and not parameter evaluation-order. These
> >>are different things, and there was a painfully long thread on exactly
> >>this subject a year or two ago.
> >>Walter closed that one by stating call-chaining can only realistically
> >>evaluate from left to right (or something to that effect) and that's
> >>what D does.
> >>I'm sure JCC could locate that thread in a heartbeat ... don't know > how he
> >
> > does that, but he sure is effective at it :)
> >
> > These days, I Usually just use Google and restrict it to www.digitalmars.com (such as the search box on the Digital Mars webpage does).
> >
> > I can't seem to track down this one though. My technique works best when I actually remember the particular post or discussion (and it works really well when I remember that I myself posted in the discussion). And I don't really remember this discussion.
> >
> > Do you happen to remember who Walter was replying to? That could be helpful. I can't seem to find the right keywords to find the particular topic. I tried various combinations of "newshound" (Walter's e-mail), "evaluation", "order", "operator", "operation", "call", "chain", "return", "function", etc. Also, sometimes it's helpful if I know when the discussion took place (Last month? Last year? 2005?). But this might just be a needle that remains hidden in the haystack.
> >
> > Perhaps we can just talk Walter into putting this principle in the D
Specification. ;)
> >
> > jcc7
> If I recall correctly, it started off as a complaint about the use of call-chaining in Mango, and resulted in someone leaving the NG for good (was his name manfred or something?)

I think this is what you're looking for:
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=31264
or
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=31264

It's part of a much larger discussion: http://www.digitalmars.com/d/archives/digitalmars/D/31069.html#N31264

(I couldn't find where anyone vowed to leave the newsgroup forever, but I suppose that does happen from time to time.)

jcc7

Sean Kelly wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Sean Kelly wrote:
>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>> Sean Kelly wrote:
>>>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>>>> Bill Baxter wrote:
>>>>>>>
>>>>>>> I believe the current discussion is only about under-the-hood implementation issues.  So I don't think you have to worry about any D libraries exposing (good or bad) C/C++ design decisions to users.  Tango is going to expose the same D interface no matter how it's implemented under the hood.
>>>>>>
>>>>>> That's great, however the interface has a problem too: it does not produce atomic strings in multithreaded programs.
>>>>>
>>>>> Which interface?  And are you talking about input or output?
>>>>
>>>> Cout. The thing is that the design using the syntax Cout(a)(b) is conducive to two separate calls to the library. I recall this has been briefly discussed here.
>>>
>>> Just making sure we were on the same page.  In my experience, raw output is typically used for logging--that's about the only case I can think of where the random interleaving of messages is acceptable.  Tango has a separate logging facility which performs synchronization for exactly this purpose: tango.util.log.  Perhaps this particular critique would be more appropriately applied to the logging package?
>>
>> I don't think so. For example, I have a multithreaded program that starts processes on multiple machines and outputs "stamped" lines to the standard output - lines with a prefix clarifying which machine the line comes from, and at what time. That output is gzipped for efficiency and transported via ethernet to a hub where the lines are demultiplexed and put into multiple files etc.
>>
>> It is essential that lines are written atomically, but beyond that, the actual order does not matter.
> 
> This sounds to me like logging output, which is exactly what I described.

Oh, I thought you meant logging as just auxiliary informative message as opposed to the meat of the I/O. Just to clarify: the interleaved output is the meat of the I/O in the case above.

> The logger could be attached to the console or a socket as easily as a file. Why use Cout for this?

"Because it's there!" :o) All a bona fide programmer expects is to have access to the three pre-opened standard streams and just use them. I'm not sure how to make a logger output to stdout. The manual (after an introduction that makes it pretty clear I'm already swimming upstream by using logger for something else than logging) says:

// send output of myLogger to stderr
myLogger.addAppender(new ConsoleAppender());

Later in the document there's the section "A Custom Appender Example" which implements what I need - not in the library, in userland. Caveat: I don't know whether that example keeps things properly multithreaded. If it does, it's deadlock-prone as it allows arbitrary code to be executed with locked files. If it doesn't, it's incorrect. Doomed either way. The lure of just using phobos' and C's stdio is so much stronger :o).

So what's the recommended use of Cout?

(a) If you do stdio, use Cout (and don't forget to flush Cout manually every time you plan to read from Cin).

(b) But not for multithreaded programs that do stdio. For those, use the logger facility. If you want multithreaded output to stdout, copy the code from http://www.dsource.org/projects/tango/wiki/ChapterLogging into your program. Be careful that that code might be incorrect; the manual doesn't specify. If it is correct, be careful with what you do inside that code, because you could deadlock yourself.

(c) And not for programs linking with anything that uses C's stdio. For those, use Phobos.


Andrei

jcc7 wrote:
> == Quote from kris (foo@bar.com)'s article
>> jcc7 wrote:
>>> == Quote from kris (foo@bar.com)'s article
>>>
>>>> Frits van Bommel wrote:
>>>> [snip]
>>>>
>>>>> What I'm trying to say here is basically this: you shouldn't rely on the
>>>>> order of evaluation of parameters. Not even if one of them happens to be
>>>>> used as 'this' for the method in question.
>>>> Absolutely agree. Yet, without wishing to go off on a tangent, we're
>>>> talking about call-chaining and not parameter evaluation-order. These
>>>> are different things, and there was a painfully long thread on exactly
>>>> this subject a year or two ago.
>>>> Walter closed that one by stating call-chaining can only realistically
>>>> evaluate from left to right (or something to that effect) and that's
>>>> what D does.
>>>> I'm sure JCC could locate that thread in a heartbeat ... don't know > how he
>>> does that, but he sure is effective at it :)
>>>
>>> These days, I Usually just use Google and restrict it to www.digitalmars.com (such
>>> as the search box on the Digital Mars webpage does).
>>>
>>> I can't seem to track down this one though. My technique works best when I
>>> actually remember the particular post or discussion (and it works really well when
>>> I remember that I myself posted in the discussion). And I don't really remember
>>> this discussion.
>>>
>>> Do you happen to remember who Walter was replying to? That could be helpful. I
>>> can't seem to find the right keywords to find the particular topic. I tried
>>> various combinations of "newshound" (Walter's e-mail), "evaluation", "order",
>>> "operator", "operation", "call", "chain", "return", "function", etc. Also,
>>> sometimes it's helpful if I know when the discussion took place (Last month? Last
>>> year? 2005?). But this might just be a needle that remains hidden in the haystack.
>>>
>>> Perhaps we can just talk Walter into putting this principle in the D
> Specification. ;)
>>> jcc7
>> If I recall correctly, it started off as a complaint about the use
>> of call-chaining in Mango, and resulted in someone leaving the NG
>> for good (was his name manfred or something?)
> 
> I think this is what you're looking for:
> http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=31264
> or
> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=31264

The information is not there.

> It's part of a much larger discussion:
> http://www.digitalmars.com/d/archives/digitalmars/D/31069.html#N31264

After a summary read I saw this:

classRef.method1().method2().method3();

In this case, indeed the three methods are evaluated in sequence. It would be, however, a mistake to infer from that that the code:

Cout("Hello, ")(Cin.get);

guaranteedly reads the console before having printed "Hello, ". It doesn't.


Andrei

== Quote from Andrei Alexandrescu (See Website For Email)
(SeeWebsiteForEmail@erdani.org)'s article
> jcc7 wrote:
> > == Quote from kris (foo@bar.com)'s article
> >> jcc7 wrote:
> >>> == Quote from kris (foo@bar.com)'s article
> >>>
> >>>> Frits van Bommel wrote:
> >>>> [snip]
> >>>>
> >>>>> What I'm trying to say here is basically this: you shouldn't rely on the order of evaluation of parameters. Not even if one of them happens to be used as 'this' for the method in question.
> >>>> Absolutely agree. Yet, without wishing to go off on a tangent, we're
> >>>> talking about call-chaining and not parameter evaluation-order. These
> >>>> are different things, and there was a painfully long thread on exactly
> >>>> this subject a year or two ago.
> >>>> Walter closed that one by stating call-chaining can only realistically
> >>>> evaluate from left to right (or something to that effect) and that's
> >>>> what D does.
> >>>> I'm sure JCC could locate that thread in a heartbeat ... don't know > how he
> >>> does that, but he sure is effective at it :)
> >>>
> >>> These days, I Usually just use Google and restrict it to www.digitalmars.com
(such
> >>> as the search box on the Digital Mars webpage does).
> >>>
> >>> I can't seem to track down this one though. My technique works best when I actually remember the particular post or discussion (and it works really
well when
> >>> I remember that I myself posted in the discussion). And I don't really remember this discussion.
> >>>
> >>> Do you happen to remember who Walter was replying to? That could be helpful. I can't seem to find the right keywords to find the particular topic. I tried various combinations of "newshound" (Walter's e-mail), "evaluation", "order", "operator", "operation", "call", "chain", "return", "function", etc. Also, sometimes it's helpful if I know when the discussion took place (Last month?
Last
> >>> year? 2005?). But this might just be a needle that remains hidden in the
haystack.
> >>>
> >>> Perhaps we can just talk Walter into putting this principle in the D
> > Specification. ;)
> >>> jcc7
> >> If I recall correctly, it started off as a complaint about the use of call-chaining in Mango, and resulted in someone leaving the NG for good (was his name manfred or something?)
> >
> > I think this is what you're looking for:
> >
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=31264
> > or
> >
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=31264
> The information is not there.
> > It's part of a much larger discussion: http://www.digitalmars.com/d/archives/digitalmars/D/31069.html#N31264
> After a summary read I saw this:
> classRef.method1().method2().method3();
> In this case, indeed the three methods are evaluated in sequence. It
> would be, however, a mistake to infer from that that the code:
> Cout("Hello, ")(Cin.get);
> guaranteedly reads the console before having printed "Hello, ". It
> doesn't.
> Andrei

Well, I don't entired understand the issue, but I may have found the wrong posting. Or maybe there is no posting where Walter addresses this issue.

jcc7

Andrei Alexandrescu (See Website For Email) wrote:
> After a summary read I saw this:
> 
> classRef.method1().method2().method3();
> 
> In this case, indeed the three methods are evaluated in sequence. It would be, however, a mistake to infer from that that the code:
> 
> Cout("Hello, ")(Cin.get);
> 
> guaranteedly reads the console before having printed "Hello, ". It doesn't.

Nobody claimed that it "guaranteedly" (whatever that means) does in the general case, so let's please move on?

The only thing asserted is that call-chaining is evaluated in left-to-right order. I think we can safely put that back to bed again

kris wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> After a summary read I saw this:
>>
>> classRef.method1().method2().method3();
>>
>> In this case, indeed the three methods are evaluated in sequence. It would be, however, a mistake to infer from that that the code:
>>
>> Cout("Hello, ")(Cin.get);
>>
>> guaranteedly reads the console before having printed "Hello, ". It doesn't.
> 
> Nobody claimed that it "guaranteedly" (whatever that means) does in the general case, so let's please move on?
> 
> The only thing asserted is that call-chaining is evaluated in left-to-right order. I think we can safely put that back to bed again

You wrote this:

-----------------------
There used to be a tango/example like this variation:

    import tango.io.Console;

    void main()
    {
        Cout ("Please enter your name: ").flush;
        Cout ("Hello, ") (Cin.get);
    }
-----------------------

The code is incorrect. Point blank. Right?


Andrei