www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3813] New: Bad writeln of string arrays

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3813

           Summary: Bad writeln of string arrays
           Product: D
           Version: 2.040
          Platform: x86
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Phobos
        AssignedTo: nobody puremagic.com
        ReportedBy: bearophile_hugs eml.cc



import std.stdio: writeln;
void main() {
    auto a = ["a", "bc"];
    writeln(a);
}

This writeln prints an ugly and misleading output:
a bc
instead of something much more realistic and useful as:
["a", "bc"]


(This is my first bug report in this bug tracker. I will probably add here some
more bugs, some of them will probably be duplicates of already present bugs.
Most of them will be bugs, I try to limit the true enhancements requests to
very few and small, because D2 is now feature frozen. All my bug reports will
be relative to D2/Phobos, but many of them can be present in D1 too. If I am
doing something wrong please tell me.)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 18 2010
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3813


Andrei Alexandrescu <andrei metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei metalanguage.com



10:33:23 PST ---
This is by design. The default array bounds were changed from "[" and "]" to ""
and "", and the default separator has been changed from ", " to " ".

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 18 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3813






 This is by design. The default array bounds were changed from "[" and "]" to ""
 and "", and the default separator has been changed from ", " to " ".


It's a bad design, much less useful than the design I have shown.
A print like:
["a", "bc"]
Tells you it's probably an array, how long it is, how long its contents are,
and the strings themselves.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 18 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3813




In dmd 2.048beta the situation is improved, but it's not good enough yet. This
D2 program:


import std.stdio, std.typetuple, std.typecons;
void main() {
    auto a1 = ["10", "20"];
    writeln(a1);
    auto a2 = [10, 20];
    writeln(a2);
    char[] a3 = ['5', '7', '9'];
    writeln(a3);
    auto t1 = TypeTuple!(10, "20", '7');
    writeln(t1);
    auto t2 = tuple(10, "20");
    writeln(t2);
}


Prints:

[10, 20]
[10, 20]
579
10207
Tuple!(int,string)(10, 20)

From that output there is now way, in both the array and the TypeTuple, to tell
apart strings, numbers and chars. This doesn't help D2 debugging, and it
doesn't help all when you write quick scripts that often use a simple writeln()
for their output. In both cases being able to tell apart numbers and strings in
the output is quite important.

So my warm suggestion is to put "" around strings, '' around chars when they
are printed inside collections (Inside string literals special chars need to be
escaped).

So my expected output is:

["10", "20"]
[10, 20]
579
10"20"'7'
Tuple!(int,string)(10, "20")


A possible alternative output:

["10", "20"]
[10, 20]
['5', '7', '9']
10"20"'7'
Tuple!(int, string)(10, "20")



A similar Python 2.7 program:

from collections import namedtuple
a1 = ["10", "20"]
print a1
a2 = [10, 20]
print a2
a3 = ['5', '7', '9']
print a3
t1 = (10, "20", '7')
print t1
t2 = namedtuple('Two', 'a b')(10, "20")
print t2



Prints:

['10', '20']
[10, 20]
['5', '7', '9']
(10, '20', '7')
Two(a=10, b='20')

(In Python strings can be delimited by '' too.)


In D I presume writeln() can't tell that the input is a TypeTuple, so it can't
print something like the () as in Python.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 09 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3813




Sorry, the expected results are wrong because writeln() can't see TypeTuple
items as inside a collection, so the expected output is:


["10", "20"]
[10, 20]
579
10207
Tuple!(int,string)(10, "20")


And the possible alternative output is:

["10", "20"]
[10, 20]
['5', '7', '9']
10207
Tuple!(int, string)(10, "20")

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 09 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3813




See also bug 4605

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 09 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3813


bearophile_hugs eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Bad writeln of string       |Bad writeln of arrays
                   |arrays                      |



See also bug 4660

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 17 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3813




See also bug 5043

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 11 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3813




import std.stdio, std.range;
void main() {
    writeln(iota(5));
}


With DMD 2.050 that program prints:

[0, 1, 2, 3, 4]

But that's not an array, it's a lazy sequence, and I'd like to be able to tell
apart an array from a lazy sequence in a printout.

A possible simple way to tell them apart is to print that lazy range like this,
like an array, but with semicolons instead of commas (in some languages this
syntax is used to tell apart linked lists from arrays, but in D lazy ranges are
probably more common than lists):

[0; 1; 2; 3; 4]

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 29 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3813


Denis Derman <denis.spir gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |denis.spir gmail.com



---


 Sorry, the expected results are wrong because writeln() can't see TypeTuple
 items as inside a collection, so the expected output is:
 
 
 ["10", "20"]
 [10, 20]
 579
 10207
 Tuple!(int,string)(10, "20")
 
 
 And the possible alternative output is:
 
 ["10", "20"]
 [10, 20]
 ['5', '7', '9']
 10207
 Tuple!(int, string)(10, "20")


I support this enhancement request.
About char[], I think using a string format rather than an array format is
better, to respect the semantics of "char" (as opposed to ubyte[]). Especially
for debugging: char[] is often used temporarily to manipulate a string, thus we
want to be able to (visually) compare it to a string.

Denis

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 16 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3813




This Python2 program:

array1 = [1, 2]
print array1
array2 = [1.0, 2.0]
print array2

Prints:
[1, 2]
[1.0, 2.0]


This similar D2 program:

import std.stdio;
void main() {
    int[2] array1 = [1, 2];
    writeln(array1);
    double[2] array2 = [1.0, 2.0];
    writeln(array2);
}


With DMD 2.051 prints:
[1, 2]
[1, 2]

A print like the one shown by Python this is better because it allows to better
tell apart visually the types of the two arrays:
[1, 2]
[1.0, 2.0]

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 08 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3813


Andrei Alexandrescu <andrei metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|nobody puremagic.com        |andrei metalanguage.com


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 08 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3813




PST ---
More generally, why don't writeln / formatValue / whatever builtin funcs used
for output simply recurse to format elements of collections. This is how things
work in all languages I know that provide default output forms. And this
default is equal, or very similar, to literal notation).
Isn't this the only sensible choice? I think we agree default output format is
primarily for programmer's feedback.

Side-point: I would love default formats for composites thingies like struct &
class objects as well. Probably another enhancement request. Currently, the
code copied below writes out:

S
modulename.C

Great! very helpful ;-) I wish we would get, as default, an output similar to
the notation needed to create the objects:

S(1, 1.1, '1', "1.1", S.Sub(1))
C(1, 1.1, '1', "1.1", new C.Sub(1))

(Except for members with default values, possibly not provided in creation
code, but listed on output.)

At least we can write a toString... but it's a bit annaoying to be forced to do
it, esp for quickly written pieces of code, when a default would do the job
(prbably most cases by far).

Denis

Code:

struct S {
    struct Sub {
        int j;
        this (int j) {
            this.j = j;
        }
    }
    int i;
    float f;
    char c;
    string s;
    Sub sub;
}

class C {
    static class Sub {
        int j;
        this (int j) {
            this.j = j;
        }
    }
    int i;
    float f;
    char c;
    string s;
    Sub sub;
    this (int i, float f, char c, string s, Sub sub) {
        this.i = i;
        this.f = f;
        this.c = c;
        this.s = s;
        this.sub = sub;
    }
}

unittest {
    S s = S(1, 1.1, '1', "1.1", S.Sub(1));
    writeln(s);
    C c = new C(1, 1.1, '1', "1.1", new C.Sub(1));
    writeln(c);
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 28 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3813


Kenji Hara <k.hara.pg gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch



---
https://github.com/D-Programming-Language/phobos/pull/126

All of ranges are formatted like "[elem1, elem2, ...]".

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 02 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3813






 https://github.com/D-Programming-Language/phobos/pull/126
 
 All of ranges are formatted like "[elem1, elem2, ...]".


I appreciate the work you are doing to improve D textual Input/Output.

Regarding lazy ranges, generally I prefer the textual output to give me hints
of what I have printed. So I'd like some difference between the textual
representation of this array:

[0, 1, 2]

And this range:

iota(3)

I think a simple way to tell them apart is to use a different separator.
Functional languages sometimes use the semicolon to separate list items, so I
think it's nice to print iota(3) like this:

[0; 1; 2]

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 02 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3813




---




 https://github.com/D-Programming-Language/phobos/pull/126
 
 All of ranges are formatted like "[elem1, elem2, ...]".


 
 I appreciate the work you are doing to improve D textual Input/Output.
 
 Regarding lazy ranges, generally I prefer the textual output to give me hints
 of what I have printed. So I'd like some difference between the textual
 representation of this array:
 
 [0, 1, 2]
 
 And this range:
 
 iota(3)
 
 I think a simple way to tell them apart is to use a different separator.
 Functional languages sometimes use the semicolon to separate list items, so I
 think it's nice to print iota(3) like this:
 
 [0; 1; 2]


I think it is nonsense to distinguish formatting between eager range (like
array) and lazy range (like iota).

Because
(1) today we cannot restore lazy range from already formatted output. We don't
have common interface to rebuild range from formatted string. Maybe OutputRange
is the I/F (call put(r, e0), put(r, e1), ... against range), but now almost
lazy ranges are not OutputRange.
And D is strict-typed language, so when you want to unformat range, you should
give range type first. So the separator will not be an issue.

(2) I think that the output like "[e0, e1, ..., eN]" is *range formatting*, not
array formatting, even if it looks like array. And an array is a kind of
ranges, so we should format them with *one* formatting.

From the reasons, it seems to me that we have no necessary to distinguish range
formattings.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 02 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3813







 (2) I think that the output like "[e0, e1, ..., eN]" is *range formatting*, not
 array formatting, even if it looks like array. And an array is a kind of
 ranges, so we should format them with *one* formatting.


Then an alternative idea is to use [,,,,] for all ranges that support random
access (std.range.isRandomAccessRange), and [;;;;] for the all the other kinds
of ranges.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 02 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3813




12:38:55 PDT ---
Let's use [,,,] for all ranges. Thanks Kenji for your work.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 04 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3813






 Let's use [,,,] for all ranges. Thanks Kenji for your work.


What's your rationale for this decision?

---------------------------

In 2.055beta the printing situation is improved a lot, thanks to your work. I
see two things where I'd like further improvement:

This code:

import std.stdio;
void main() {
    int[2] array1 = [1, 2];
    writeln(array1);
    double[2] array2 = [1.0, 2.0];
    writeln(array2);
}


With DMD 2.055beta prints:
[1, 2]
[1, 2]

This is not good, because from the text you can't tell FP point numbers from
integer ones. In a similar situation Python prints this, that I think is a
better output:

[1.0, 2.0]
[1.0, 2.0]

------------------------------

This code:

import std.stdio, std.typecons;
void main () {
    writeln(tuple(1, "xx"));
}


Prints:
Tuple!(int,string)(1, xx)


But I'd like:
tuple(1, "xx")


That's closer to array representation, because D tuples are not TypeTuples,
they have a different semantics (with a TypeTuple is probably better to not
print the "" around strings).

Python does something similar (Python uses ' insted if " but this is not
relevant):


 (1, "xx")






(1, 'xx')

--------------------------

This is a less important thing. This code:


import std.stdio;
void main () {
    writeln([1:2, 3:4]);
}


Prints:
[1:2, 3:4]


While Python 2.6 prints:


 {1:2, 3:4}






{1: 2, 3: 4}

Python adds a space after the colon probably to increase readability.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 05 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3813







 This is not good, because from the text you can't tell FP point numbers from
 integer ones. In a similar situation Python prints this, that I think is a
 better output:
 
 [1.0, 2.0]
 [1.0, 2.0]


Sorry, I meant:

[1, 2]
[1.0, 2.0]

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 05 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3813




---



 

 This is not good, because from the text you can't tell FP point numbers from
 integer ones. In a similar situation Python prints this, that I think is a
 better output:
 
 [1.0, 2.0]
 [1.0, 2.0]


 
 Sorry, I meant:
 
 [1, 2]
 [1.0, 2.0]


If you want that result, following code will work.

writefln("[%(%.1f, %)]", array2);  // prints [1.0, 2.0]

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 05 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3813







 If you want that result, following code will work.
 
 writefln("[%(%.1f, %)]", array2);  // prints [1.0, 2.0]


What I meant to say is that I'd like
writeln([1.0, 2.0])

To print this one default:
[1.0, 2.0]

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 05 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3813




06:02:55 PDT ---




 Let's use [,,,] for all ranges. Thanks Kenji for your work.


 
 What's your rationale for this decision?


Absent other considerations, more consistency is better than less consistency.
You keep on asking for arbitrary differentiation of kinds of ranges in their
textual representation without any rationale. The burden is on you to justify
the inconsistency, not on Kenji to justify consistency.

Plus, the requests you are making now are self-contradictory. First, you want
the representation of the array to clarify its type:


 [1, 2]
 [1.0, 2.0]


This marginally differentiates floating point types from integral types.
However it's an incomplete solution as it doesn't differentiate across
float/double/real or short/int/long/uint etc. But let's note that here you are
asking for a format that helps type differentiation.

One paragraph below (!) you are asking for the exact opposite: less type
differentiation. You want to change


 Tuple!(int,string)(1, xx)


to


 tuple(1, "xx")


Both changes have pros and cons, but there's no guiding rationale behind them.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 05 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3813







 more consistency is better than less consistency.


Consistency is good when the situations don't change. But in our discussions
the conditions weren't invariant, because the range types (random access or
not) are different.

The different separators is not an important feature, so if you aren't
interested I'll stop asking for it. It's just a cute little thing that I think
gives a little help.



 You keep on asking for arbitrary differentiation of kinds of ranges in their
 textual representation without any rationale. The burden is on you to justify
 the inconsistency, not on Kenji to justify consistency.


The desire to tell apart lazy ranges from random access ranges comes from the
desire to give more information to the person that reads the textual output.
This is expecially useful in dynamically typed languages, but it's useful in D
too, because you use "auto" definition, template type values, and generally
reading textual outputs it's not always easy to know what part of the printout
is generated by a specific writeln.



 Plus, the requests you are making now are self-contradictory.


The moderate self-contradictory nature of what I've said comes from practical
considerations. See below.



 First, you want the representation of the array to clarify its type:
 

 [1, 2]
 [1.0, 2.0]


 
 This marginally differentiates floating point types from integral types.
 However it's an incomplete solution as it doesn't differentiate across
 float/double/real or short/int/long/uint etc. But let's note that here you are
 asking for a format that helps type differentiation.


Currently D allows implicit casts between float/double/real. But you can't
implicitly cast an int to float. So while float and double are two different
types just as int and double are two different types, in D double and real are
less different than a double and an int. So the D definition of "different
type" is not fully binary, it's a bit fuzzy.

(It can be argued that a good textual representation of floats/reals has to
contain a leading "F"/"L". I think this is a bit overkill, but it's not so
bad.)



 One paragraph below (!) you are asking for the exact opposite: less type
 differentiation. You want to change
 

 Tuple!(int,string)(1, xx)


 
 to
 

 tuple(1, "xx")


 
 Both changes have pros and cons, but there's no guiding rationale behind them.


There is a rationale: I'd like the textual representation to be as informative
as possible, and possibly to be "invertible" too (so "unprinting" it gives back
the original value or data structure), unless this goes too much against other
practical considerations (like output space, output readability, etc).

Writing on default a double as 2.0 instead of 2 is good because it tells me
that I have printed a value of one of the floating point types
(float/double/real or some other library defined FP value). In several
situations it's useful to know if a value is integral or not.

Printing a tuple like:

Tuple!(int,string)(1, xx)

Is bad because the second argument is not what you see in the code, so if you
"unprint" it you get an error (unless you add a special case for this
situation, but this is not good and it doesn't scale).

(Doing the same for a TypeTuple is acceptable, in my opinion.)

So this is a better textual representation:

Tuple!(int,string)(1, "xx")

Currently if you print an array of strings you get:

["xx", "yy"]

Because this allows unprinting, is more readable, etc. For consistency with
string array printing, I'd like tuples to do the same (while TypeTuples are
very different from arrays).


Now think about an array of tuples, if you print one of them you get something
like:

[Tuple!(int,string)(1, "aa"), Tuple!(int,string)(2, "bb"),
Tuple!(int,string)(3, "cc"),
 Tuple!(int,string)(4, "dd"), Tuple!(int,string)(1, "ee"),
Tuple!(int,string)(1, "ff"),
 Tuple!(int,string)(1, "gg"), ...]

Here in my opinion there is too much noise, most of the space is used by
redudant things. This is why I have suggested to print tuples, when they are
inside a collection, in a shorter way:

[tuple(1, "aa"), tuple(2, "bb"), tuple(3, "cc"),
 tuple(4, "dd"), tuple(1, "ee"), tuple(1, "ff"),
 tuple(1, "gg"), ...]

Or even (but this can't be unprinted, so this is probably eccessive):

[(1, "aa"), (2, "bb"), (3, "cc"), (4, "dd"), (1, "ee"), (1, "ff"), (1, "gg"),
...]


On the other hand if I print a single tuple, outside of collections, then
showing the full typing is usually acceptable:

Tuple!(int,string)(1, "xx")


In arrays of FP values the ".0" adds add just two chars and only to numbers
that don't already have one or more decimal digit. So the added ".0" doesn't
add too much noise (unlike adding "Tuple!(int,string)").

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 05 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3813


Andrei Alexandrescu <andrei metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED



19:11:33 PDT ---



 

 more consistency is better than less consistency.


 
 Consistency is good when the situations don't change. But in our discussions
 the conditions weren't invariant, because the range types (random access or
 not) are different.


This doesn't make sense, so I wouldn't know how to answer.

Anyhow, first you wanted ';' to denote lazy vs. eager ranges. Now you want it
to denote random access vs. other ranges - all irrelevant features to printing
ranges. This forces someone who e.g. wants to parse some range to special-case
things because the emitter of the string used a random-access range or not.
This, again, makes no sense. For all I can tell you'd be happy as long as ';'
vs. ',' differentiates _some_ aspect of a range, it doesn't really matter
which. 


 The different separators is not an important feature, so if you aren't
 interested I'll stop asking for it. It's just a cute little thing that I think
 gives a little help.


Please don't frame me as the arbiter. I'm just pointing out some nonsense.


 You keep on asking for arbitrary differentiation of kinds of ranges in their
 textual representation without any rationale. The burden is on you to justify
 the inconsistency, not on Kenji to justify consistency.


 
 The desire to tell apart lazy ranges from random access ranges comes from the
 desire to give more information to the person that reads the textual output.
 This is expecially useful in dynamically typed languages, but it's useful in D
 too, because you use "auto" definition, template type values, and generally
 reading textual outputs it's not always easy to know what part of the printout
 is generated by a specific writeln.


So you want differentiation, it doesn't matter on what feature. Numeric vs.
non-numeric seems fair game too.


 Currently D allows implicit casts between float/double/real. But you can't
 implicitly cast an int to float. So while float and double are two different
 types just as int and double are two different types, in D double and real are
 less different than a double and an int. So the D definition of "different
 type" is not fully binary, it's a bit fuzzy.


No, it's quite binary. Two types are identical or not.


 (It can be argued that a good textual representation of floats/reals has to
 contain a leading "F"/"L". I think this is a bit overkill, but it's not so
 bad.)
 
 

 One paragraph below (!) you are asking for the exact opposite: less type
 differentiation. You want to change
 

 Tuple!(int,string)(1, xx)


 
 to
 

 tuple(1, "xx")


 
 Both changes have pros and cons, but there's no guiding rationale behind them.


 
 There is a rationale: I'd like


What one likes is not rationale.


 the textual representation to be as informative
 as possible, and possibly to be "invertible" too (so "unprinting" it gives back
 the original value or data structure), unless this goes too much against other
 practical considerations (like output space, output readability, etc).


But in the same breath you propose tuple(1, "hello") instead of Tuple!(int,
string) although it could originate from a Tuple!(short, char[]). Your own
requests are dissonant with your own desiderata. To be frank, you quite
literally don't know what you want. Why are we spending our valuable time on
this?


 Writing on default a double as 2.0 instead of 2 is good because it tells me
 that I have printed a value of one of the floating point types
 (float/double/real or some other library defined FP value). In several
 situations it's useful to know if a value is integral or not.


It's also bad because it takes more space.


 Printing a tuple like:
 
 Tuple!(int,string)(1, xx)
 
 Is bad because the second argument is not what you see in the code, so if you
 "unprint" it you get an error (unless you add a special case for this
 situation, but this is not good and it doesn't scale).
 
 (Doing the same for a TypeTuple is acceptable, in my opinion.)
 
 So this is a better textual representation:
 
 Tuple!(int,string)(1, "xx")


I agree that printing a tuple should produce unambiguous representation of its
fields, but that's different from your request that the type of Tuple is
replaced with the word "tuple".


 Currently if you print an array of strings you get:
 
 ["xx", "yy"]
 
 Because this allows unprinting, is more readable, etc. For consistency with
 string array printing, I'd like tuples to do the same (while TypeTuples are
 very different from arrays).


So now you list unprinting as a desideratum yet it's only seconds after you
asked for making that gratuitously difficult by using ';' vs. ',' on some
arbitrary criterion.


 Now think about an array of tuples, if you print one of them you get something
 like:
 
 [Tuple!(int,string)(1, "aa"), Tuple!(int,string)(2, "bb"),
 Tuple!(int,string)(3, "cc"),
  Tuple!(int,string)(4, "dd"), Tuple!(int,string)(1, "ee"),
 Tuple!(int,string)(1, "ff"),
  Tuple!(int,string)(1, "gg"), ...]
 
 Here in my opinion there is too much noise, most of the space is used by
 redudant things. This is why I have suggested to print tuples, when they are
 inside a collection, in a shorter way:
 
 [tuple(1, "aa"), tuple(2, "bb"), tuple(3, "cc"),
  tuple(4, "dd"), tuple(1, "ee"), tuple(1, "ff"),
  tuple(1, "gg"), ...]
 
 Or even (but this can't be unprinted, so this is probably eccessive):
 
 [(1, "aa"), (2, "bb"), (3, "cc"), (4, "dd"), (1, "ee"), (1, "ff"), (1, "gg"),
 ...]
 
 
 On the other hand if I print a single tuple, outside of collections, then
 showing the full typing is usually acceptable:
 
 Tuple!(int,string)(1, "xx")
 
 
 In arrays of FP values the ".0" adds add just two chars and only to numbers
 that don't already have one or more decimal digit. So the added ".0" doesn't
 add too much noise (unlike adding "Tuple!(int,string)").


Quite honestly I think the noise is in this discussion. I am closing this
report. Sorry.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 05 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3813







 Why are we spending our valuable time on this?


Because I print tuples often, and I'd like to see this situation improved. See
also:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=143987



 Quite honestly I think the noise is in this discussion.


It was an useful discussion already:
http://d.puremagic.com/issues/show_bug.cgi?id=6606

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 06 2011