http://d.puremagic.com/issues/show_bug.cgi?id=3813



--- Comment #10 from bearophile_hugs@eml.cc 2011-01-08 03:30:24 PST ---
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: -------

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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3813



--- Comment #11 from Denis Derman <denis.spir@gmail.com> 2011-01-28 06:08:53 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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3813


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

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


--- Comment #12 from Kenji Hara <k.hara.pg@gmail.com> 2011-09-02 12:04:18 PDT ---
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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3813



--- Comment #13 from bearophile_hugs@eml.cc 2011-09-02 15:11:43 PDT ---
(In reply to comment #12)
> 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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3813



--- Comment #14 from Kenji Hara <k.hara.pg@gmail.com> 2011-09-02 16:00:43 PDT ---
(In reply to comment #13)
> (In reply to comment #12)
> > 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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3813



--- Comment #15 from bearophile_hugs@eml.cc 2011-09-02 16:38:20 PDT ---
(In reply to comment #14)

> (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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3813



--- Comment #16 from Andrei Alexandrescu <andrei@metalanguage.com> 2011-09-04 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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3813



--- Comment #17 from bearophile_hugs@eml.cc 2011-09-05 02:53:08 PDT ---
(In reply to comment #16)
> 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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3813



--- Comment #18 from bearophile_hugs@eml.cc 2011-09-05 02:55:45 PDT ---
(In reply to comment #17)

> 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: -------