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