www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Just because it's a slow Thursday on this forum

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
https://github.com/D-Programming-Language/phobos/pull/3971 -- Andrei
Feb 04 2016
next sibling parent reply Tofu Ninja <emmons0 purdue.edu> writes:
On Thursday, 4 February 2016 at 15:33:41 UTC, Andrei Alexandrescu 
wrote:
 https://github.com/D-Programming-Language/phobos/pull/3971 -- 
 Andrei
People one github were asking for a dump function so they could do int a = 5; dump!("a"); // prints "a = 5" Here's a working version if anyone wants it but you have to use it like mixin dump!("a"); //------------------------------------------------ mixin template dump(Names ... ) { auto _unused_dump = { import std.stdio : writeln, write; foreach(i,name; Names) { write(name, " = ", mixin(name), (i<Names.length-1)?", ": "\n"); } return false; }(); } unittest{ int x = 5; int y = 3; int z = 15; mixin dump!("x", "y"); // x = 5, y = 3 mixin dump!("z"); // z = 15 mixin dump!("x+y"); // x+y = 8 mixin dump!("x+y < z");// x+y < z = true }
Feb 04 2016
next sibling parent Tofu Ninja <emmons0 purdue.edu> writes:
On Friday, 5 February 2016 at 02:46:01 UTC, Tofu Ninja wrote:
 ...
It's kinda neat cus it supports arbitrary expressions. Mixins are pretty powerful.
Feb 04 2016
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 02/04/2016 09:46 PM, Tofu Ninja wrote:
 On Thursday, 4 February 2016 at 15:33:41 UTC, Andrei Alexandrescu wrote:
 https://github.com/D-Programming-Language/phobos/pull/3971 -- Andrei
People one github were asking for a dump function so they could do int a = 5; dump!("a"); // prints "a = 5" Here's a working version if anyone wants it but you have to use it like mixin dump!("a"); //------------------------------------------------ mixin template dump(Names ... ) { auto _unused_dump = { import std.stdio : writeln, write; foreach(i,name; Names) { write(name, " = ", mixin(name), (i<Names.length-1)?", ": "\n"); } return false; }(); } unittest{ int x = 5; int y = 3; int z = 15; mixin dump!("x", "y"); // x = 5, y = 3 mixin dump!("z"); // z = 15 mixin dump!("x+y"); // x+y = 8 mixin dump!("x+y < z");// x+y < z = true }
This is useful and we should include it. How would you improve the code to allow dumping to a different File than stdout (e.g. most often stderr)? -- Andrei
Feb 07 2016
next sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Sunday, 7 February 2016 at 23:26:05 UTC, Andrei Alexandrescu 
wrote:
 On 02/04/2016 09:46 PM, Tofu Ninja wrote:
 On Thursday, 4 February 2016 at 15:33:41 UTC, Andrei 
 Alexandrescu wrote:
 https://github.com/D-Programming-Language/phobos/pull/3971 -- 
 Andrei
People one github were asking for a dump function so they could do int a = 5; dump!("a"); // prints "a = 5" Here's a working version if anyone wants it but you have to use it like mixin dump!("a"); //------------------------------------------------ mixin template dump(Names ... ) { auto _unused_dump = { import std.stdio : writeln, write; foreach(i,name; Names) { write(name, " = ", mixin(name), (i<Names.length-1)?", ": "\n"); } return false; }(); } unittest{ int x = 5; int y = 3; int z = 15; mixin dump!("x", "y"); // x = 5, y = 3 mixin dump!("z"); // z = 15 mixin dump!("x+y"); // x+y = 8 mixin dump!("x+y < z");// x+y < z = true }
This is useful and we should include it. How would you improve the code to allow dumping to a different File than stdout (e.g. most often stderr)? -- Andrei
Something like this? import std.stdio : File, stderr, stdout; template dumpTo(alias output) if (isInstanceOf!(File, output)) { mixin template dumpTo(Names ... ) { auto _unused_dump = { import std.traits : Select; foreach (i, name; Names) { output.write(name, " = ", mixin(name), Select!(i < Names.length - 1, ", ", '\n')); } return false; }(); } } alias dump = dumpTo!stdout; alias errDump = dumpTo!stderr;
Feb 07 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/7/16 7:11 PM, John Colvin wrote:
 alias dump = dumpTo!stdout;
 alias errDump = dumpTo!stderr;
I'm hoping for something with a simpler syntax, a la dump!(stdout, "x") where stdout is optional. -- Andrei
Feb 08 2016
next sibling parent Tourist <gravatar gravatar.com> writes:
On Monday, 8 February 2016 at 13:37:19 UTC, Andrei Alexandrescu 
wrote:
 On 2/7/16 7:11 PM, John Colvin wrote:
 alias dump = dumpTo!stdout;
 alias errDump = dumpTo!stderr;
I'm hoping for something with a simpler syntax, a la dump!(stdout, "x") where stdout is optional. -- Andrei
dump and fdump, just like printf and fprintf?
Feb 08 2016
prev sibling next sibling parent John Colvin <john.loughran.colvin gmail.com> writes:
On Monday, 8 February 2016 at 13:37:19 UTC, Andrei Alexandrescu 
wrote:
 On 2/7/16 7:11 PM, John Colvin wrote:
 alias dump = dumpTo!stdout;
 alias errDump = dumpTo!stderr;
I'm hoping for something with a simpler syntax, a la dump!(stdout, "x") where stdout is optional. -- Andrei
How about this, which allows you to specify variables as alias parameters (i.e. without strings) as well. It could be a lot neater if a static assert is used in the body instead of using template constraints, but obviously that has its downsides. import std.stdio : File; import std.traits : isSomeString; import std.meta : allSatisfy; private template isAlias(a ...) if (a.length == 1) { enum isAlias = __traits(compiles, { alias b = a[0]; }) && is(typeof(a[0])); } private template isStringValue(a ...) if (a.length == 1) { enum isStringValue = isSomeString!(typeof(a[0])); } private template isStringOrAlias(a ...) if (a.length == 1) { /* can't use templateOr in the dump template constraints * because `Error: template instance F!(a) cannot use local 'a' * as parameter to non-global template templateOr(T...)` */ * enum isStringOrAlias = isAlias!a || isStringValue!a; } mixin template dump(alias file, Args ...) if (is(typeof(file) == File) && Args.length > 0 && allSatisfy!(isStringOrAlias, Args)) { auto _unused_dump = { import std.traits : Select; // can put expressions directly in Select with // https://github.com/D-Programming-Language/phobos/pull/3978 enum sep = ", "; enum term = "\n"; foreach (i, arg; Args) { static if (isSomeString!(typeof(arg))) file.write(arg, " = ", mixin(arg), Select!(i < Args.length - 1, sep, term)); else file.write(__traits(identifier, Args[i]), " = ", arg, Select!(i < Args.length - 1, sep, term)); } return false; }(); } mixin template dump(Args ...) if (Args.length > 0 && allSatisfy!(isStringOrAlias, Args)) { import std.stdio : stdout; mixin .dump!(stdout, Args); } unittest { import std.stdio; int a = 3, b = 4; mixin dump!q{ a + b }; mixin dump!(stderr, "a - b"); mixin dump!a; mixin dump!(stderr, a, b); }
Feb 08 2016
prev sibling next sibling parent reply Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
On Monday, 8 February 2016 at 13:37:19 UTC, Andrei Alexandrescu 
wrote:
 On 2/7/16 7:11 PM, John Colvin wrote:
 alias dump = dumpTo!stdout;
 alias errDump = dumpTo!stderr;
I'm hoping for something with a simpler syntax, a la dump!(stdout, "x") where stdout is optional. -- Andrei
Why would `stdout` need to be a template argument?
Feb 09 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 02/09/2016 06:25 AM, Marc Sch├╝tz wrote:
 On Monday, 8 February 2016 at 13:37:19 UTC, Andrei Alexandrescu wrote:
 On 2/7/16 7:11 PM, John Colvin wrote:
 alias dump = dumpTo!stdout;
 alias errDump = dumpTo!stderr;
I'm hoping for something with a simpler syntax, a la dump!(stdout, "x") where stdout is optional. -- Andrei
Why would `stdout` need to be a template argument?
It needn't! -- Andrei
Feb 09 2016
prev sibling parent reply Jakob Ovrum <jakobovrum gmail.com> writes:
On Monday, 8 February 2016 at 13:37:19 UTC, Andrei Alexandrescu 
wrote:
 On 2/7/16 7:11 PM, John Colvin wrote:
 alias dump = dumpTo!stdout;
 alias errDump = dumpTo!stderr;
I'm hoping for something with a simpler syntax, a la dump!(stdout, "x") where stdout is optional. -- Andrei
This works: --- import std.stdio : File; static import std.ascii; template dump(symbols...) { import std.stdio : File; void dump(Separator, Terminator)( File file, Separator separator = ", ", Terminator terminator = std.ascii.newline) { foreach(i, symbol; symbols[0 .. $ - 1]) file.write(__traits(identifier, symbols[i]), " = ", symbol, separator); file.write(__traits(identifier, symbols[$ - 1]), " = ", symbols[$ - 1], terminator); } void dump(Separator, Terminator)( Separator separator = ", ", Terminator terminator = std.ascii.newline) if (!is(Separator == File)) { import std.stdio : stdout; .dump!symbols(stdout, separator, terminator); } } void main() { import std.stdio : stdout; int a = 42; string b = "foo"; float c = 3.14; dump!(a, b, c)(); // a = 42, b = foo, c = 3.14 stdout.dump!(a, b, c)(" | "); // a = 42 | b = foo | c = 3.14 } --- I'm not a fan of non-trivial string mixins except in extenuating circumstances. I tried compressing it to a single call to `write` like your `print` except using staticMap, but like I often do I ran into "template instance foo cannot use local 'bar' as parameter to non-global template baz" errors.
Feb 09 2016
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 02/09/2016 07:46 AM, Jakob Ovrum wrote:
 void main()
 {
      import std.stdio : stdout;

      int a = 42;
      string b = "foo";
      float c = 3.14;

      dump!(a, b, c)(); // a = 42, b = foo, c = 3.14
      stdout.dump!(a, b, c)(" | "); // a = 42 | b = foo | c = 3.14
 }
I think this is good stuff and should go in Phobos. Where particularly? -- Andrei
Feb 09 2016
parent Jakob Ovrum <jakobovrum gmail.com> writes:
On Tuesday, 9 February 2016 at 14:38:23 UTC, Andrei Alexandrescu 
wrote:
 On 02/09/2016 07:46 AM, Jakob Ovrum wrote:
 void main()
 {
      import std.stdio : stdout;

      int a = 42;
      string b = "foo";
      float c = 3.14;

      dump!(a, b, c)(); // a = 42, b = foo, c = 3.14
      stdout.dump!(a, b, c)(" | "); // a = 42 | b = foo | c = 
 3.14
 }
I think this is good stuff and should go in Phobos. Where particularly? -- Andrei
I can't really see the applications beyond a role as a simple lowtech debugging aid, but since it uses std.stdio I guess that's an OK place to put it.
Feb 09 2016
prev sibling parent reply ixid <nuaccount gmail.com> writes:
On Tuesday, 9 February 2016 at 12:46:34 UTC, Jakob Ovrum wrote:
 I'm not a fan of non-trivial string mixins except in 
 extenuating circumstances.
This is something Steven Schveighoffer commented on in these discussions as well. As this is a fundamental D feature and it's currently rather clunky and hard to use it would suggest this needs improvement. What should be done with it if anything and with what methods?
Feb 09 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 02/09/2016 10:34 AM, ixid wrote:
 On Tuesday, 9 February 2016 at 12:46:34 UTC, Jakob Ovrum wrote:
 I'm not a fan of non-trivial string mixins except in extenuating
 circumstances.
This is something Steven Schveighoffer commented on in these discussions as well. As this is a fundamental D feature and it's currently rather clunky and hard to use it would suggest this needs improvement. What should be done with it if anything and with what methods?
An alternate solution is liable to be too clever for its own good. Everybody and their cat understands string concatenation. What we need here is better tactical tools, e.g. a simple string template/interpolation engine. -- Andrei
Feb 09 2016
next sibling parent ixid <nuaccount gmail.com> writes:
On Tuesday, 9 February 2016 at 18:02:50 UTC, Andrei Alexandrescu 
wrote:
 On 02/09/2016 10:34 AM, ixid wrote:
 An alternate solution is liable to be too clever for its own 
 good. Everybody and their cat understands string concatenation. 
 What we need here is better tactical tools, e.g. a simple 
 string template/interpolation engine. -- Andrei
I wasn't suggesting throwing the baby out with the bathwater. Library and IDE support to what's there would be great.
Feb 10 2016
prev sibling parent reply Suliman <evermind live.ru> writes:
On Tuesday, 9 February 2016 at 18:02:50 UTC, Andrei Alexandrescu 
wrote:
 On 02/09/2016 10:34 AM, ixid wrote:
 On Tuesday, 9 February 2016 at 12:46:34 UTC, Jakob Ovrum wrote:
 I'm not a fan of non-trivial string mixins except in 
 extenuating
 circumstances.
This is something Steven Schveighoffer commented on in these discussions as well. As this is a fundamental D feature and it's currently rather clunky and hard to use it would suggest this needs improvement. What should be done with it if anything and with what methods?
An alternate solution is liable to be too clever for its own good. Everybody and their cat understands string concatenation. What we need here is better tactical tools, e.g. a simple string template/interpolation engine. -- Andrei
Sorry, but where dump! function can be helpful? What's wrong with writeln?
Feb 10 2016
next sibling parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Dne 10.2.2016 v 15:06 Suliman via Digitalmars-d napsal(a):
 On Tuesday, 9 February 2016 at 18:02:50 UTC, Andrei Alexandrescu wrote:
 On 02/09/2016 10:34 AM, ixid wrote:
 On Tuesday, 9 February 2016 at 12:46:34 UTC, Jakob Ovrum wrote:
 I'm not a fan of non-trivial string mixins except in extenuating
 circumstances.
This is something Steven Schveighoffer commented on in these discussions as well. As this is a fundamental D feature and it's currently rather clunky and hard to use it would suggest this needs improvement. What should be done with it if anything and with what methods?
An alternate solution is liable to be too clever for its own good. Everybody and their cat understands string concatenation. What we need here is better tactical tools, e.g. a simple string template/interpolation engine. -- Andrei
Sorry, but where dump! function can be helpful? What's wrong with writeln?
It is something else. Same as php has echo and var_dump. writeln just output value of some variable, but dump will print names and values of variables, so you can see structure of your data.
Feb 10 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 02/10/2016 09:22 AM, Daniel Kozak via Digitalmars-d wrote:
 It is something else. Same as php has echo and var_dump. writeln just
 output value of some variable, but dump will print names and values of
 variables, so you can see structure of your data.
Oh btw one nice thing about dump would be to display strings in "dson" format, i.e. the same way they'd appear in a D declaration. Example: s = "This is\na\tstring." writeln(s) would output: ==== This is a string. ==== whereas dump!(s) would write: ==== s = "This is\na\tstring." ==== Andrei
Feb 10 2016
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 10 February 2016 at 14:06:02 UTC, Suliman wrote:
 Sorry, but where dump! function can be helpful? What's wrong 
 with writeln?
Formatting complex data automatically makes it a lot easier to see what you're getting. Makes debugging so much easier when your data is actually readable. Long strings, complex structs, byte arrays, json or xml, these all really need more formatting to read than writeln does.
Feb 10 2016
prev sibling parent reply Nick Sabalausky <a a.a> writes:
On Sunday, 7 February 2016 at 23:26:05 UTC, Andrei Alexandrescu 
wrote:
 On 02/04/2016 09:46 PM, Tofu Ninja wrote:
 On Thursday, 4 February 2016 at 15:33:41 UTC, Andrei 
 Alexandrescu wrote:
 https://github.com/D-Programming-Language/phobos/pull/3971 -- 
 Andrei
People one github were asking for a dump function so they could do int a = 5; dump!("a"); // prints "a = 5" Here's a working version if anyone wants it but you have to use it like mixin dump!("a"); //------------------------------------------------ mixin template dump(Names ... ) { auto _unused_dump = { import std.stdio : writeln, write; foreach(i,name; Names) { write(name, " = ", mixin(name), (i<Names.length-1)?", ": "\n"); } return false; }(); } unittest{ int x = 5; int y = 3; int z = 15; mixin dump!("x", "y"); // x = 5, y = 3 mixin dump!("z"); // z = 15 mixin dump!("x+y"); // x+y = 8 mixin dump!("x+y < z");// x+y < z = true }
This is useful and we should include it. How would you improve the code to allow dumping to a different File than stdout (e.g. most often stderr)? -- Andrei
FWIW, That functionality's been in the "semitwist d tools" util lib for years. (Although granted, much of the lib has bitrotted by this point.) See "traceVal". I'd wanted to do a non-mixin version, but that hasn't been possible. That was a major motivator for my suggestion ages ago of "string mixins without the mixin keyword by marking a ctfe func as mixin" but that was rejected in favor of only allowing it for template mixins, not string mixins.
Feb 08 2016
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 02/08/2016 02:15 PM, Nick Sabalausky wrote:
 I'd wanted to do a non-mixin version, but that hasn't been possible.
Well, wasn't possible at the time, anyway.
Feb 09 2016
prev sibling parent reply w0rp <devw0rp gmail.com> writes:
I wonder if the addition of another function for printing will 
confuse some new users.
Feb 10 2016
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Feb 10, 2016 at 06:51:21PM +0000, w0rp via Digitalmars-d wrote:
 I wonder if the addition of another function for printing will confuse
 some new users.
Currently I don't see much value in it to justify the costs. BUT, there might be a case for it if: 1) It's clear that it's only intended for debugging (i.e., the name should make it clear it isn't for general output, so `dump` rather than `print` would be preferable); 2) It's actually useful for debugging, meaning: a) It will use introspection to recursively output aggregate members (preferably with field members labelled); b) Arrays and AA likewise should be output in the expected format; c) Attributes, and perhaps the full type, should be included in the output, especially if function pointers and delegates are involved, e.g.: const(char)[] data = ...; int delegate(float) safe dg; dump(data, dg); should output something like: (const(char)[])"Some string data", (int delegate(float) safe)0x12345678 (Why the full type? because it's useful for debugging `auto` variables in range-based code and other such code. And also to make it absolutely clear that this isn't meant for anything other than debugging output.) d) It will, optionally, walk recursive data structures and output each node in some sensible way. 3) The output format should be standard, readable by default, and should not need (nor allow) customization. (Otherwise, we might as well go back to writefln & friends.) T -- It is impossible to make anything foolproof because fools are so ingenious. -- Sammy
Feb 10 2016
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 02/10/2016 02:08 PM, H. S. Teoh via Digitalmars-d wrote:
 On Wed, Feb 10, 2016 at 06:51:21PM +0000, w0rp via Digitalmars-d wrote:
 I wonder if the addition of another function for printing will confuse
 some new users.
I can't imagine it would in any significant way. Certainly not if it's named "dump", anyway.
 Currently I don't see much value in it to justify the costs.

 BUT,

 there might be a case for it if:

 [...]
I see no non-trivial cost. I've been using a homemade equivalent of it for years, and I can speak from experience that it's definitely a big help. Not only that, but the only two reasons I've ever had for NOT using it are fixed by this proposal: - Can now be done without bulky "mixin(...)" at the usage site. - Built into Phobos so never a need, in any project, to [temporarily or otherwise] tie in a new dependency just for a temporary debugging aid. I'm hugely in favor of this. Me want.
Feb 10 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 02/10/2016 02:25 PM, Nick Sabalausky wrote:
 I see no non-trivial cost.
I, to, am not getting the cost story. H.S. Teoh, could you please substantiate? -- Andrei
Feb 10 2016
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Feb 10, 2016 at 02:32:37PM -0500, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 02/10/2016 02:25 PM, Nick Sabalausky wrote:
I see no non-trivial cost.
I, to, am not getting the cost story. H.S. Teoh, could you please substantiate? -- Andrei
Sorry, I meant technical debt. My point was that this function needs to provide more value than what's effectively just an alias for writefln("%s, %s, %s", x, y, z). T -- Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte
Feb 10 2016
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 02/10/2016 02:47 PM, H. S. Teoh via Digitalmars-d wrote:
 On Wed, Feb 10, 2016 at 02:32:37PM -0500, Andrei Alexandrescu via
Digitalmars-d wrote:
 On 02/10/2016 02:25 PM, Nick Sabalausky wrote:
 I see no non-trivial cost.
I, to, am not getting the cost story. H.S. Teoh, could you please substantiate? -- Andrei
Sorry, I meant technical debt. My point was that this function needs to provide more value than what's effectively just an alias for writefln("%s, %s, %s", x, y, z).
Having used an equivalent to the proposed "dump" for many years (and an inferior equivalent at that), I can attest that it definitely provides sufficient value over write* functions. With write*, there's always either excess verbosity that just gets in the way of my "flow", or I can opt the succinct route and wind up looking at a dump of numbers finding it difficult to know what number is what variable. Any homemade wrapper/alias only creates even MORE work when trying to use it. Anyone may be skeptical of the reasons, but it doesn't matter because again, this is all direct personal experience, not hypothetical theorizing. In short: Yes. Yes it does provide sufficient value. And the "technical debt" is still vastly less than the time, effort and bother of having to defend yet another clear improvement on the D perpetual debate forums.
Feb 11 2016
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Feb 11, 2016 at 09:55:49AM -0500, Nick Sabalausky via Digitalmars-d
wrote:
 On 02/10/2016 02:47 PM, H. S. Teoh via Digitalmars-d wrote:
On Wed, Feb 10, 2016 at 02:32:37PM -0500, Andrei Alexandrescu via Digitalmars-d
wrote:
On 02/10/2016 02:25 PM, Nick Sabalausky wrote:
I see no non-trivial cost.
I, to, am not getting the cost story. H.S. Teoh, could you please substantiate? -- Andrei
Sorry, I meant technical debt. My point was that this function needs to provide more value than what's effectively just an alias for writefln("%s, %s, %s", x, y, z).
Having used an equivalent to the proposed "dump" for many years (and an inferior equivalent at that), I can attest that it definitely provides sufficient value over write* functions. With write*, there's always either excess verbosity that just gets in the way of my "flow", or I can opt the succinct route and wind up looking at a dump of numbers finding it difficult to know what number is what variable. Any homemade wrapper/alias only creates even MORE work when trying to use it. Anyone may be skeptical of the reasons, but it doesn't matter because again, this is all direct personal experience, not hypothetical theorizing. In short: Yes. Yes it does provide sufficient value. And the "technical debt" is still vastly less than the time, effort and bother of having to defend yet another clear improvement on the D perpetual debate forums.
Fair enough. Personally, though, I find a bunch of comma-separated values very unhelpful. It would be much better if they were labelled, e.g., if: int x, y, z; dump(x,y,z); outputs: x=1, y=2, z=3 it would be much better than just: 1, 2, 3 which is unclear which values belongs to which variable. Trivial to figure out in this case, but it's not as obvious when interspersed between other program output & debug messages. But maybe that's just a matter of habit, and difference in personal debugging style. T -- Making non-nullable pointers is just plugging one hole in a cheese grater. -- Walter Bright
Feb 11 2016
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 02/11/2016 11:22 AM, H. S. Teoh via Digitalmars-d wrote:
 Personally, though, I find a bunch of comma-separated values very
 unhelpful. It would be much better if they were labelled
So wasn't this dump() as opposed to print()? Two different functions doing different things. -- Andrei
Feb 11 2016
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 02/11/2016 11:22 AM, H. S. Teoh via Digitalmars-d wrote:
 Fair enough.

 Personally, though, I find a bunch of comma-separated values very
 unhelpful. It would be much better if they were labelled, e.g., if:

 	int x, y, z;
 	dump(x,y,z);

 outputs:

 	x=1, y=2, z=3

 it would be much better than just:

 	1, 2, 3

 which is unclear which values belongs to which variable. Trivial to
 figure out in this case, but it's not as obvious when interspersed
 between other program output & debug messages. But maybe that's just a
 matter of habit, and difference in personal debugging style.
My understanding is that's the whole point of the "dump" function being discussed. Unless I misunderstood?
Feb 11 2016
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Feb 11, 2016 at 03:38:42PM -0500, Nick Sabalausky via Digitalmars-d
wrote:
 On 02/11/2016 11:22 AM, H. S. Teoh via Digitalmars-d wrote:
Fair enough.

Personally, though, I find a bunch of comma-separated values very
unhelpful. It would be much better if they were labelled, e.g., if:

	int x, y, z;
	dump(x,y,z);

outputs:

	x=1, y=2, z=3

it would be much better than just:

	1, 2, 3

which is unclear which values belongs to which variable. Trivial to
figure out in this case, but it's not as obvious when interspersed
between other program output & debug messages. But maybe that's just
a matter of habit, and difference in personal debugging style.
My understanding is that's the whole point of the "dump" function being discussed. Unless I misunderstood?
IMO `dump` is worthwhile but `print` seems little more than an alias for `writefln`. I can't find enough justification to warrant `print`. (Next thing you know, newbies will be asking why there's both `print` and `write` that do the same thing except different.) T -- In order to understand recursion you must first understand recursion.
Feb 11 2016
next sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Thursday, 11 February 2016 at 21:38:42 UTC, H. S. Teoh wrote:
 On Thu, Feb 11, 2016 at 03:38:42PM -0500, Nick Sabalausky via 
 Digitalmars-d wrote:
 On 02/11/2016 11:22 AM, H. S. Teoh via Digitalmars-d wrote:
[...]
My understanding is that's the whole point of the "dump" function being discussed. Unless I misunderstood?
IMO `dump` is worthwhile but `print` seems little more than an alias for `writefln`. I can't find enough justification to warrant `print`. (Next thing you know, newbies will be asking why there's both `print` and `write` that do the same thing except different.) T
yeah, dump is really useful, print is a bit marginal.
Feb 11 2016
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 02/11/2016 04:44 PM, John Colvin wrote:
 On Thursday, 11 February 2016 at 21:38:42 UTC, H. S. Teoh wrote:
 On Thu, Feb 11, 2016 at 03:38:42PM -0500, Nick Sabalausky via
 Digitalmars-d wrote:
 On 02/11/2016 11:22 AM, H. S. Teoh via Digitalmars-d wrote:
[...]
My understanding is that's the whole point of the "dump" function being discussed. Unless I misunderstood?
IMO `dump` is worthwhile but `print` seems little more than an alias for `writefln`. I can't find enough justification to warrant `print`. (Next thing you know, newbies will be asking why there's both `print` and `write` that do the same thing except different.) T
yeah, dump is really useful, print is a bit marginal.
Ahh, I missed the "print" stuff. I do agree it's not as useful as "dump", plus the name seems to suggest a connection with printf, which strikes me as confusing. I do think the "print" function discussed (ie, like writeln, but auto-inserts spaces between the args) is occasionally nice for script-like programs. In fact, I think I have a function like that in Scriptlike specifically because of that...unless it's back in my older utility library instead... I'd be perfectly happy to have it, particularly if it had a less confusing name, but can definitely see it being debatable whether it really is Phobos-worthy.
Feb 11 2016
parent ixid <nuaccount gmail.com> writes:
On Friday, 12 February 2016 at 03:18:47 UTC, Nick Sabalausky 
wrote:
 I'd be perfectly happy to have it, particularly if it had a 
 less confusing name, but can definitely see it being debatable 
 whether it really is Phobos-worthy.
Andrei has previously expressed a desire for a big standard library and it is a very good introduction to the language for newbies to be able to use print. It's simple and does what they expect, writefln("%s %s %s %s", a, b, c, d) is anything but simple and contains multiple pitfalls for a new user. This is likely the second most commonly used function (or thing someone wants a function to do) after main. Why is the resistance to convenience functions so high in this community? If you want people to use D it will need to be both powerful and feel light and easy to use. It would seem to be better for D to allow convenience functions in Phobos more broadly where the use case is common. There are already many print and write functions, it's not a thing that has only one way to do it that will be greatly muddied by the addition of another function, can you cite threads from other languages where people are confused by a function called print that prints?
Feb 12 2016
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/11/16 4:38 PM, H. S. Teoh via Digitalmars-d wrote:
 (Next
 thing you know, newbies will be asking why there's both `print` and
 `write` that do the same thing except different.)
That sounds unlikely to me. What would be a few examples/precedents? -- Andrei
Feb 12 2016
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 02/10/2016 02:08 PM, H. S. Teoh via Digitalmars-d wrote:
 1) It's clear that it's only intended for debugging (i.e., the name
 should make it clear it isn't for general output, so `dump` rather than
 `print` would be preferable);
Those would be two different functions. -- Andrei
Feb 10 2016
prev sibling next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 10 February 2016 at 18:51:21 UTC, w0rp wrote:
 I wonder if the addition of another function for printing will 
 confuse some new users.
I'm a relatively new D user. For the most part, all I use is writeln because that's what was used in the Hello World examples. I only bother looking for other printing functions when I need them. Nevertheless, I struggle with some of the documentation in std.stdio. A few functions, like byChunk, are documented in a high-quality way. For others, the situation is not so good. Look at stdout, just says standard output stream. There's no definition of stream anywhere in there, or a link to maybe the wikipedia page on streams. When I google output stream it brings up Java documentation. I happen to know what it means and someone with other programming experience will too, but not a new programmer. Many other functions are documented in a similarly terse fashion. So no, I don't think adding another function to std.stdio will be confusing ipso facto. Instead, if you think new users will find std.stdio confusing, may I suggest improving the documentation (of both old and new functionality).
Feb 10 2016
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 02/10/2016 01:51 PM, w0rp wrote:
 I wonder if the addition of another function for printing will confuse
 some new users.
In my experience: * two names for the same exact thing => annoyance (not only in D, e.g. dual use of "class" and "typename" in C++) * two different names that do the same thing in slightly different without a distinction, interchangeable ways => confusion and annoyance (e.g. "class" vs "struct" in C++) * two names that do the same thing, one poorly and one better => confusion (e.g. "stringstream" vs. "strstream", vector<bool> vs vector_bool in C++) * two names that do two similar, but distinct things => "oh ok" (e.g. "map" vs. "multimap"). So I think we're safe. Andrei
Feb 10 2016
parent w0rp <devw0rp gmail.com> writes:
On Wednesday, 10 February 2016 at 19:30:26 UTC, Andrei 
Alexandrescu wrote:
 On 02/10/2016 01:51 PM, w0rp wrote:
 I wonder if the addition of another function for printing will 
 confuse
 some new users.
In my experience: * two names for the same exact thing => annoyance (not only in D, e.g. dual use of "class" and "typename" in C++) * two different names that do the same thing in slightly different without a distinction, interchangeable ways => confusion and annoyance (e.g. "class" vs "struct" in C++) * two names that do the same thing, one poorly and one better => confusion (e.g. "stringstream" vs. "strstream", vector<bool> vs vector_bool in C++) * two names that do two similar, but distinct things => "oh ok" (e.g. "map" vs. "multimap"). So I think we're safe. Andrei
Yeah, that makes sense. Fair enough.
Feb 10 2016