www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - best replacement for - cout << "hello D" << endl; ?

reply Bruce Adams <tortoise_74 no.spam.ya.hoo.co.uk> writes:
Hi,
   The biggest single problem with D is that its a very very bad search term
for google. I usually add phobos but that doesn't always help.
   I'm trying to find the 'best' replacement for C++ streaming I/O.
I dislike C style format strings because of the type safety issue and run time
interpretation issues. I'm pretty sure D works around this using a typeinfo
array but I keep losing the function. I understand that writefln is now
favoured over printf (http://www.prowiki.org/wiki4d/wiki.cgi?HowTo/printf).
I've also seen a dout floating around which isn't quite what I'm hoping for. I
thought I saw an article a few years back decrying the operator<< syntax and
describing D's replacement.
Can anyone point me in the right direction? This really ought to be in the C++
vs D FAQ (http://www.digitalmars.com/d/faq.html)


Regards,

Bruce.
Jul 10 2007
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Bruce Adams" <tortoise_74 no.spam.ya.hoo.co.uk> wrote in message 
news:f71fdt$rfp$1 digitalmars.com...
 Hi,
   The biggest single problem with D is that its a very very bad search 
 term for google. I usually add phobos but that doesn't always help.

The accepted search term is becoming "D programming language" or just "D programming". Walter's been pushing that for a while now, and suggests that D sites include the phrase at least once. Keep in mind that "C" is a pretty terrible search term too ;)
   I'm trying to find the 'best' replacement for C++ streaming I/O.
 I dislike C style format strings because of the type safety issue and run 
 time interpretation issues. I'm pretty sure D works around this using a 
 typeinfo array but I keep losing the function. I understand that writefln 
 is now favoured over printf 
 (http://www.prowiki.org/wiki4d/wiki.cgi?HowTo/printf).

Type safety is not an issue with Phobos' formatting strings; they just happen to look like printf's formatting. In fact you can just use %s for everything, and it'll figure it all out at runtime. However if runtime type identification for formatted printing is not what you're looking for, you won't find any alternative in Phobos. For that, there's Tango (http://www.dsource.org/projects/Tango), an alternative community-driven standard library for D which is quickly gaining popularity. One of Tango's claims to fame is its much more flexible and powerful IO framework. I'm not sure if it still provides the C++ style << and >> for writing and reading (they may have been removed), but it uses the same basic idea of chained overloaded operator calls, but using the call operator instead of the shift operators. For example, here is a use of the Stdout object, similar to C++'s cout: import tango.io.Stdout; void main() { int x = 6; Stdout("X is: ")(x).newline; } Like in C++ streams, each item is outputted separately, and uses its own method overload, avoiding runtime type identification. Objects which read use the same syntax (called "whisper" for reasons I don't entirely understand ;) ). Of course there's also C#-style formatted printing: Stdout.formatln("X is: {}", x); Which, like Phobos' format() family of function (including writefln()), uses RTTI to correctly output the formatted values. This is also necessary for any custom formatting, such as outputting hex integers or field widths, since there is no analogue to the i.e. ios::hex as in C++ for the chained output method.
Jul 10 2007
parent reply Bruce Adams <tortoise_74 ya.nospam.hoo.co.uk> writes:
Jarrett Billingsley Wrote:

 "Bruce Adams" <tortoise_74 no.spam.ya.hoo.co.uk> wrote in message 
 news:f71fdt$rfp$1 digitalmars.com...
 
   I'm trying to find the 'best' replacement for C++ streaming I/O.
 I dislike C style format strings because of the type safety issue and run 
 time interpretation issues. I'm pretty sure D works around this using a 
 typeinfo array but I keep losing the function. I understand that writefln 
 is now favoured over printf 
 (http://www.prowiki.org/wiki4d/wiki.cgi?HowTo/printf).

Type safety is not an issue with Phobos' formatting strings; they just happen to look like printf's formatting. In fact you can just use %s for everything, and it'll figure it all out at runtime. However if runtime type identification for formatted printing is not what you're looking for, you won't find any alternative in Phobos.

std.format.doFormat almost does what I want. It takes any array of TypeInfo objects and another array of arguments so that at there is at least a chance for type safety of some of the conversion being enforced at compile time. What is "dout" for? When would you use it instead of stdout?
 For that, there's Tango (http://www.dsource.org/projects/Tango), an 
 alternative community-driven standard library for D which is quickly gaining 
 popularity.  One of Tango's claims to fame is its much more flexible and 
 powerful IO framework.  I'm not sure if it still provides the C++ style << 
 and >> for writing and reading (they may have been removed), but it uses the 
 same basic idea of chained overloaded operator calls, but using the call 
 operator instead of the shift operators.  For example, here is a use of the 
 Stdout object, similar to C++'s cout:
 
 import tango.io.Stdout;
 
 void main()
 {
     int x = 6;
     Stdout("X is: ")(x).newline;
 }
 
 Like in C++ streams, each item is outputted separately, and uses its own 
 method overload, avoiding runtime type identification.  Objects which read 
 use the same syntax (called "whisper" for reasons I don't entirely 
 understand ;) ).

 Of course there's also C#-style formatted printing:
 
 Stdout.formatln("X is: {}", x);
 
 Which, like Phobos' format() family of function (including writefln()), uses 
 RTTI to correctly output the formatted values.  This is also necessary for 
 any custom formatting, such as outputting hex integers or field widths, 
 since there is no analogue to the i.e. ios::hex as in C++ for the chained 
 output method. 

Jul 11 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Bruce Adams wrote:

 import tango.io.Stdout;

 void main()
 {
     int x = 6;
     Stdout("X is: ")(x).newline;
 }

 Like in C++ streams, each item is outputted separately, and uses its own 
 method overload, avoiding runtime type identification.  Objects which read 
 use the same syntax (called "whisper" for reasons I don't entirely 
 understand ;) ).


Some folks actually really dig it. I can't say I'm a huge fan, but I'll admit it looks better to me << than << "lots" << of << "<<" << everywhere << endl. About enforcing type safety at compile time, I don't think doFormat does any compile time checking. As far as I know, the only compile time formatters are experimental things, based on the growing CFTE string parsing functionality in D. --bb
Jul 11 2007
prev sibling next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Bruce Adams wrote:
I haven't found a page on operator overloading yet 

Here ya go: http://www.digitalmars.com/d/1.0/operatoroverloading.html
Jul 11 2007
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
Bruce Adams wrote:
 Jarrett Billingsley Wrote:
 
 "Bruce Adams" <tortoise_74 no.spam.ya.hoo.co.uk> wrote in message 
 news:f71fdt$rfp$1 digitalmars.com...

   I'm trying to find the 'best' replacement for C++ streaming I/O.
 I dislike C style format strings because of the type safety issue and run 
 time interpretation issues. I'm pretty sure D works around this using a 
 typeinfo array but I keep losing the function. I understand that writefln 
 is now favoured over printf 
 (http://www.prowiki.org/wiki4d/wiki.cgi?HowTo/printf).

happen to look like printf's formatting. In fact you can just use %s for everything, and it'll figure it all out at runtime. However if runtime type identification for formatted printing is not what you're looking for, you won't find any alternative in Phobos.

std.format.doFormat almost does what I want. It takes any array of TypeInfo objects and another array of arguments so that at there is at least a chance for type safety of some of the conversion being enforced at compile time. What is "dout" for? When would you use it instead of stdout?
 For that, there's Tango (http://www.dsource.org/projects/Tango), an 
 alternative community-driven standard library for D which is quickly gaining 
 popularity.  One of Tango's claims to fame is its much more flexible and 
 powerful IO framework.  I'm not sure if it still provides the C++ style << 
 and >> for writing and reading (they may have been removed), but it uses the 
 same basic idea of chained overloaded operator calls, but using the call 
 operator instead of the shift operators.  For example, here is a use of the 
 Stdout object, similar to C++'s cout:

 import tango.io.Stdout;

 void main()
 {
     int x = 6;
     Stdout("X is: ")(x).newline;
 }

 Like in C++ streams, each item is outputted separately, and uses its own 
 method overload, avoiding runtime type identification.  Objects which read 
 use the same syntax (called "whisper" for reasons I don't entirely 
 understand ;) ).


Yuck. Operator overloading should not be ambiguous. Each operator should mean one thing and one thing only, or as close as possible. When I see ++ in code, it should indicate that some form of incrementation is going on, not that something is being sent to a stream somewhere. I shouldn't need to know the context in which the operator is being used in order to determine what is going on. There's absolutely no reason to use operator overloads for IO when function calls do the job just fine. The use of << and >> for IO in C++ is one of that languages nastiest features. Anything remotely resembling it has no place in D.
Jul 11 2007
next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Mike Parker wrote

 Anything remotely resembling it has no place in D.

Confirmed. Additional remark: The cuurent semantics of chaining relies on an existing but unspecified evaluation order. This might turn out to be a shot in the leg according to the specs: | It is an error to depend on order of evaluation when it is not | specified. -manfred
Jul 11 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Manfred Nowak wrote:
 Additional remark:
 The cuurent semantics of chaining relies on an existing but unspecified 
 evaluation order. This might turn out to be a shot in the leg according 
 to the specs:
 | It is an error to depend on order of evaluation when it is not
 | specified.

As has been posted on these newsgroups before (including, IIRC, by Walter) order of evaluation when using chaining is not a problem unless calculating the extra values has side-effects. For example, in --- Stdout("a")(1)("b"); --- the values of "a", 1 and "b" may be determined in any order, but they will be passed to the output in the order they appear. The code that gets executed is equivalent to --- foo(foo(foo(Stdout, "a"), 1), "b"); --- where each inner foo must be executed before execution of an outer one can start because the inner foo returns a value used as a parameter of the outer foo (the 'this' value of opCall). In other words: it's *not* an error to depend on order of evaluation when it *is* specified. :)
Jul 11 2007
parent Manfred Nowak <svv1999 hotmail.com> writes:
Frits van Bommel wrote

 As has been posted on these newsgroups before (including, IIRC, by 
 Walter) order of evaluation when using chaining is not a problem

Confirmed---but it is still not mentioned in the specs, on which I rely---and there might be a reason other than Walters overload with work.
 In other words: it's *not* an error to depend on order of
 evaluation when it *is* specified. :)

:) according to the known boolean rules, it might turn out, that all :) one can deduce from the cited sentence of the specs is: :) If there is no error then the order is specified :) which is quite less than you seem to see -manfred
Jul 11 2007
prev sibling parent reply Bruce Adams <tort.oise74 do.not.yahoo.spam.me.co.uk> writes:
 
 Yuck. Operator overloading should not be ambiguous. Each operator should 
 mean one thing and one thing only, or as close as possible. When I see 
 ++ in code, it should indicate that some form of incrementation is going 
 on, not that something is being sent to a stream somewhere. I shouldn't 
 need to know the context in which the operator is being used in order to 
 determine what is going on. There's absolutely no reason to use operator 
 overloads for IO when function calls do the job just fine.
 
 The use of << and >> for IO in C++ is one of that languages nastiest 
 features. Anything remotely resembling it has no place in D.

Well yes and no. I find myself using the << and >> operators to mean streaming 99% of the time. I use them for shifting much less often. I thought I read that the argument about operator overloading was one reason D wasn't going to have it a while back. A year or two on and here we are. I don't want to have to use format strings because of the type safety issues (unless you go down the C# {} route) stdout << foo << bar << 2 << std::endl; Is more concise than: stdout.write(foo); stdout.write(bar); stdout.write(2); stdout.wrteln(); and type safe compared to: stdout.writefln("%s%s%i", foo,bar,2); as nothing ensures foo and bar are strings or 2 is a integer or even that there are enough arguments at compile time. A compromise like the following still wouldn't solve the number of arguments problem. typeinfo[] types = { char[], char[], int }; stdout.write("%%%", types, foo, bar, 2); lint for C would probably tell me to add a ,0 as a sentinel as well. With true arrays that shouldn't be a problem for D. Can we do some clever template foo to make something like the following work? typeinfo[] types = { char[], char[], int }; object[] args = { foo, bar, 2 }; stdout.write!(types, object); Of course then I'd want a way of constructing lists of objects easily like foo+bar+2 or cons(foo,bar,2); or use write!(typeinfo[],...) but crucially one that works at compile time. Actually why bother with the typeinfo[] at all. How about: stdout.write!(...) --> foreach (arg;list) { stdout.write(list); } but with typeof or some such template foo to make it expand at compile time. I think this would remove the need for << by turning: cout << foo << bar << 2 << endl; into: stdout.write!(foo,bar,2,endl); Any takers? Look like I still want an IO manipulator class hierarchy. Regards, Bruce.
Jul 11 2007
parent reply Carlos Santander <csantander619 gmail.com> writes:
Bruce Adams escribió:
 
 and type safe compared to:
 
 stdout.writefln("%s%s%i", foo,bar,2);
 

D has typesafe variadics, so you can just say: dout.writefln("%s%s%s", foo,bar,2); %s doesn't mean "pretend it's a string," but rather "write its string representation." -- Carlos Santander Bernal
Jul 11 2007
next sibling parent reply Bruce Adams <tortoise_74 ya.nos.pam.hoo.co.uk> writes:
Carlos Santander Wrote:

 Bruce Adams escribió:
 
 and type safe compared to:
 
 stdout.writefln("%s%s%i", foo,bar,2);
 

D has typesafe variadics, so you can just say: dout.writefln("%s%s%s", foo,bar,2); %s doesn't mean "pretend it's a string," but rather "write its string representation." -- Carlos Santander Bernal

I see. That makes quite a lot of difference. Now is there a way to remove the format string entirely. a) as a function b) as a template that can be expanded at compile time. It sounds like its trivial to write a) if it doesn't already exist. Hopefully, it does though. Regards, Bruce.
Jul 11 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Bruce Adams wrote:
 Carlos Santander Wrote:
 
 Bruce Adams escribió:
 and type safe compared to:

 stdout.writefln("%s%s%i", foo,bar,2);

dout.writefln("%s%s%s", foo,bar,2); %s doesn't mean "pretend it's a string," but rather "write its string representation." -- Carlos Santander Bernal

I see. That makes quite a lot of difference. Now is there a way to remove the format string entirely. a) as a function b) as a template that can be expanded at compile time.

Easier than that: writefln("This is test number ", i, " out of ", num_tests, " test(s)."); But it doesn't really buy you any safety over the %s version. It doesn't do anything differently except maybe avoid a tiny bit of string processing to extract and replace the "%s" strings.
 It sounds like its trivial to write a) if it doesn't already exist. Hopefully,
it does though.

--bb
Jul 11 2007
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Bruce Adams" <tortoise_74 ya.nos.pam.hoo.co.uk> wrote in message 
news:f7445a$1g7g$1 digitalmars.com...
 I see. That makes quite a lot of difference. Now is there a way to remove 
 the format string entirely.
  a) as a function
  b) as a template that can be expanded at compile time.

 It sounds like its trivial to write a) if it doesn't already exist. 
 Hopefully, it does though.

Bill showed one way to do it with writefln, which still happens all at runtime. Another way is with variadic templates: void myWritefln(T...)(T args) { foreach(arg; args) writef("%s", arg); writefln(); } myWritefln("Hi! ", 5, " that's all."); There are a few things to note about this: 1) That foreach loop in the function is actually run at compile time and unrolled; if you call this function with three arguments, the body will be repeated three times, once for each argument. 2) You don't necessarily have to use writef[ln]() on the inside; you could use this to wrap Tango-style (blah)(x) output in a more natural-looking function call. 3) The issue with this is code bloat -- an instance of this template is created for each separate list of parameter types. (But ignoring the code bloat, it's just too damn cool of a feature not to use it ;) ) Furthermore some people (as has been mentioned in this thread) have been working on compile-time formatting which checks that the formatting strings match up, typewise, with their arguments.
Jul 11 2007
parent reply Bruce Adams <tortoise_74 ya.dont.spam.me.hoo.co.uk> writes:
Jarrett Billingsley Wrote:

 "Bruce Adams" <tortoise_74 ya.nos.pam.hoo.co.uk> wrote in message 
 news:f7445a$1g7g$1 digitalmars.com...
 I see. That makes quite a lot of difference. Now is there a way to remove 
 the format string entirely.
  a) as a function
  b) as a template that can be expanded at compile time.

 It sounds like its trivial to write a) if it doesn't already exist. 
 Hopefully, it does though.

Bill showed one way to do it with writefln, which still happens all at runtime. Another way is with variadic templates: void myWritefln(T...)(T args) { foreach(arg; args) writef("%s", arg); writefln(); } myWritefln("Hi! ", 5, " that's all."); There are a few things to note about this: 1) That foreach loop in the function is actually run at compile time and unrolled; if you call this function with three arguments, the body will be repeated three times, once for each argument.

I see this is actually in the example for variadic templates. http://www.digitalmars.com/d/variadic-function-templates.html Just one small problem. I can't get it to compile. At first I thought you were using incomplete/pseudo code to demonstrate but now I'm guessing maybe the compiler I'm using is incomplete. void myWritefln(T...)(T args) // line 7 { foreach(arg; args) // line 9 writef("%s", arg); writefln(); } test.d:7: found '...' when expecting ')' test.d:7: semicolon expected following function declaration test.d:7: Declaration expected, not ')' test.d:9: no identifier for declarator args test.d:9: semicolon expected, not ')' test.d:9: Declaration expected, not ')' test.d:12: no identifier for declarator writefln test.d:13: unrecognized declaration F:\projects>gdc --version gdc (GCC) 3.4.4 (cygming special, gdc 0.23, using dmd 1.007)) Before I post this as a bug can someone check I haven't made a noob error. Regards, Bruce.
Jul 11 2007
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Bruce Adams wrote:
 Jarrett Billingsley Wrote:
 

 void myWritefln(T...)(T args)
 {
     foreach(arg; args)
         writef("%s", arg);

     writefln();
 }

 myWritefln("Hi! ", 5, " that's all.");



I see this is actually in the example for variadic templates. http://www.digitalmars.com/d/variadic-function-templates.html Just one small problem. I can't get it to compile. At first I thought you were using incomplete/pseudo code to demonstrate but now I'm guessing maybe the compiler I'm using is incomplete. void myWritefln(T...)(T args) // line 7 { foreach(arg; args) // line 9 writef("%s", arg); writefln(); } test.d:7: found '...' when expecting ')' test.d:7: semicolon expected following function declaration test.d:7: Declaration expected, not ')' test.d:9: no identifier for declarator args test.d:9: semicolon expected, not ')' test.d:9: Declaration expected, not ')' test.d:12: no identifier for declarator writefln test.d:13: unrecognized declaration F:\projects>gdc --version gdc (GCC) 3.4.4 (cygming special, gdc 0.23, using dmd 1.007))

It was /slightly/ incomplete, but I can't reproduce your error messages. This works for me, using "gdc (GCC) 4.1.1 20060524 ( (gdc 0.23, using dmd 1.007))" (Linux x64 version): --- import std.stdio; void myWritefln(T...)(T args) { foreach(arg; args) writef("%s", arg); writefln(); } void main() { myWritefln("Hi! ", 5, " that's all."); } ---
Jul 12 2007
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Carlos Santander wrote:
 Bruce Adams escribió:
 and type safe compared to:

 stdout.writefln("%s%s%i", foo,bar,2);

D has typesafe variadics, so you can just say: dout.writefln("%s%s%s", foo,bar,2);

Or just dout.writefln(foo,bar,2); in this case.
 %s doesn't mean "pretend it's a string," but rather "write its string 
 representation."

I agree that compile time type-checked format parameters would be nice. writefln("%d", someObject); >> ERROR: someObject is not an integer Would be nice. A couple of people were trying to get this to work using compile time string processing. Maybe they'll pipe in here at some point... --bb
Jul 11 2007
next sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Bill Baxter wrote:
 Carlos Santander wrote:
 Bruce Adams escribió:
 and type safe compared to:

 stdout.writefln("%s%s%i", foo,bar,2);

D has typesafe variadics, so you can just say: dout.writefln("%s%s%s", foo,bar,2);

Or just dout.writefln(foo,bar,2); in this case.

That would cause foo and possibly (if no '%' in foo) bar to be interpreted as format strings. The %i can safely be left out though.
Jul 12 2007
prev sibling parent Don Clugston <dac nospam.com.au> writes:
Bill Baxter wrote:
 Carlos Santander wrote:
 Bruce Adams escribió:
 and type safe compared to:

 stdout.writefln("%s%s%i", foo,bar,2);

D has typesafe variadics, so you can just say: dout.writefln("%s%s%s", foo,bar,2);

Or just dout.writefln(foo,bar,2); in this case.
 %s doesn't mean "pretend it's a string," but rather "write its string 
 representation."

I agree that compile time type-checked format parameters would be nice. writefln("%d", someObject); >> ERROR: someObject is not an integer Would be nice. A couple of people were trying to get this to work using compile time string processing. Maybe they'll pipe in here at some point... --bb

mixin(Writefln(`"%d", someObject`)); will work perfectly (including error messages pointing to the line of the user's code), but it's just too ugly. The nice thing about it is, there's no template bloat, and no use of RTTI. It is also already possible to do: Writefln!("%d")(someObject); also a bit ugly, and with code bloat. All we need is a tiny bit of syntax sugar.
Jul 19 2007
prev sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Bruce Adams" <tortoise_74 ya.nospam.hoo.co.uk> wrote in message 
news:f720t3$6m5$1 digitalmars.com...
 What is "dout" for? When would you use it instead of stdout?

dout (in std.cstream) is a Stream (std.stream) wrapped around the C stdout. Basically it just provides an object-oriented interface to it. Look up std.stream.InputStream/OutputStream/Stream for info on the methods that it supports.
 That is so ugly. I haven't found a page on operator overloading yet but 
 there must be better choices availabe. Even ++ as a binary operator would 
 be better.

I don't know what to say. I think << and >> look terrible. To each his own.
Jul 11 2007
prev sibling parent reply "Craig Black" <cblack ara.com> writes:
I agree with most that the use of << and >> or other forms of operator 
overloading are inappropriate to process variable number of arguments.  D 
has variable template args built in to the freakin language.  It's typesafe, 
elegant, and straightforward.

// C++ yuck
cout << "x is " << x << endl;

// Tango yuck
Stdout("x is ")(x).newline;

// Would be best and very easy to implement
write("x is ", x, newline);

-Craig 
Jul 12 2007
next sibling parent BCS <ao pathlink.com> writes:
Reply to Craig,

 I agree with most that the use of << and >> or other forms of operator
 overloading are inappropriate to process variable number of arguments.
 D has variable template args built in to the freakin language.  It's
 typesafe, elegant, and straightforward.
 
 // C++ yuck
 cout << "x is " << x << endl;
 // Tango yuck
 Stdout("x is ")(x).newline;
 // Would be best and very easy to implement
 write("x is ", x, newline);
 -Craig
 

how about: alias Teritef!("this is the format %B %xL %eR\n") myWrite; // args == (bool, long, real) output = (T/F, hex, exponent) My only issue is that it needs to be some sort of wrapper or huge code bloat will be a problem.
Jul 12 2007
prev sibling next sibling parent reply kris <foo bar.com> writes:
Craig Black wrote:
 // Tango yuck
 Stdout("x is ")(x).newline;

It not at all clear why some folks have latched onto the above syntax as some kind of figurehead :) This is Tango formatting: # Stdout.formatln ("x is {}, y is {}, z is {}", x, y, z); along with this variation for handling I18N argument indexing: # Stdout.formatln ("x is {2}, y is {0}, z is {1}", y, z, x); Yes, there are optional formatting specifiers within the {} also. It just so happens that Tango /also/ supports non-formatted output using the same entity: # Stdout (x); And, for those who just need to output some values quickly, sans formatting, the same call handles more than one argument: # Stdout (x, y, z); Notice the lack of formatting text in the above? Instead it simply emits ", " between the arguments, since that is how it is written in the call. It just so happens that Stdout also returns itself, which can be used for chaining purposes. Hence, you /can/ use it in the following manner: Stdout (x) (y) (z); Tango has an idiom of returning a chaining instance when there's nothing much else of value to return. The above is just a continuation of that general pattern, and does not imply some kind of usage requirement. I hope this helps to clarify somewhat?
Jul 12 2007
next sibling parent reply "Craig Black" <cblack ara.com> writes:
Oh OK.  Tango is now redeemed.

"kris" <foo bar.com> wrote in message news:f75sn0$187s$1 digitalmars.com...
 Craig Black wrote:
 // Tango yuck
 Stdout("x is ")(x).newline;

It not at all clear why some folks have latched onto the above syntax as some kind of figurehead :) This is Tango formatting: # Stdout.formatln ("x is {}, y is {}, z is {}", x, y, z); along with this variation for handling I18N argument indexing: # Stdout.formatln ("x is {2}, y is {0}, z is {1}", y, z, x); Yes, there are optional formatting specifiers within the {} also. It just so happens that Tango /also/ supports non-formatted output using the same entity: # Stdout (x); And, for those who just need to output some values quickly, sans formatting, the same call handles more than one argument: # Stdout (x, y, z); Notice the lack of formatting text in the above? Instead it simply emits ", " between the arguments, since that is how it is written in the call. It just so happens that Stdout also returns itself, which can be used for chaining purposes. Hence, you /can/ use it in the following manner: Stdout (x) (y) (z); Tango has an idiom of returning a chaining instance when there's nothing much else of value to return. The above is just a continuation of that general pattern, and does not imply some kind of usage requirement. I hope this helps to clarify somewhat?

Jul 12 2007
parent kris <foo bar.com> writes:
Craig Black wrote:
 Oh OK.  Tango is now redeemed.

Thank goodness :-)
 
 "kris" <foo bar.com> wrote in message news:f75sn0$187s$1 digitalmars.com...
 Craig Black wrote:
 // Tango yuck
 Stdout("x is ")(x).newline;

some kind of figurehead :) This is Tango formatting: # Stdout.formatln ("x is {}, y is {}, z is {}", x, y, z); along with this variation for handling I18N argument indexing: # Stdout.formatln ("x is {2}, y is {0}, z is {1}", y, z, x); Yes, there are optional formatting specifiers within the {} also. It just so happens that Tango /also/ supports non-formatted output using the same entity: # Stdout (x); And, for those who just need to output some values quickly, sans formatting, the same call handles more than one argument: # Stdout (x, y, z); Notice the lack of formatting text in the above? Instead it simply emits ", " between the arguments, since that is how it is written in the call. It just so happens that Stdout also returns itself, which can be used for chaining purposes. Hence, you /can/ use it in the following manner: Stdout (x) (y) (z); Tango has an idiom of returning a chaining instance when there's nothing much else of value to return. The above is just a continuation of that general pattern, and does not imply some kind of usage requirement. I hope this helps to clarify somewhat?


Jul 12 2007
prev sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
kris wrote:
 Craig Black wrote:
 // Tango yuck
 Stdout("x is ")(x).newline;

It not at all clear why some folks have latched onto the above syntax as some kind of figurehead :)

I think its a factor of a few things. 1) Remembrance of the "whisper" syntax's debut in DSC/Mango. (I can't actually remember if it was present in DSC before the name change...) 2) The fact that it did somehow end up the common way of using Stdout for some while (although I personally use .format() more often anymore). 3) A certain long and elaborate discussion about the reliability of call chaining, where "whisper" became the central case study. 4) The mysteries of human nature. :) -- Chris Nicholson-Sauls
Jul 12 2007
parent reply kris <foo bar.com> writes:
Chris Nicholson-Sauls wrote:
 I think its a factor of a few things.
 
 1) Remembrance of the "whisper" syntax's debut in DSC/Mango.  (I can't 
 actually remember if it was present in DSC before the name change...)

You remember that far back? :)
Jul 12 2007
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
kris wrote:
 Chris Nicholson-Sauls wrote:
 I think its a factor of a few things.

 1) Remembrance of the "whisper" syntax's debut in DSC/Mango.  (I can't 
 actually remember if it was present in DSC before the name change...)

You remember that far back? :)

The dsc.io package was a life (ok, time) saver for me then. Heck yeah I remember it. ;) -- Chris Nicholson-Sauls
Jul 13 2007
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Craig Black Wrote:

 // Tango yuck
 Stdout("x is ")(x).newline;

Like anything else, it's a matter of taste. I dind the massive quantities of parentheses good visual separation.
Jul 12 2007
parent "Craig Black" <cblack ara.com> writes:
More power to ya!

"Robert Fraser" <fraserofthenight gmail.com> wrote in message 
news:f762u9$1l5l$1 digitalmars.com...
 Craig Black Wrote:

 // Tango yuck
 Stdout("x is ")(x).newline;

Like anything else, it's a matter of taste. I dind the massive quantities of parentheses good visual separation.

Jul 12 2007