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



--- Comment #19 from Kenji Hara <k.hara.pg@gmail.com> 2011-09-05 03:11:08 PDT ---
(In reply to comment #18)
> (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]

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

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



--- Comment #20 from bearophile_hugs@eml.cc 2011-09-05 04:12:39 PDT ---
(In reply to comment #19)

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

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



--- Comment #21 from Andrei Alexandrescu <andrei@metalanguage.com> 2011-09-05 06:02:55 PDT ---
(In reply to comment #17)
> (In reply to comment #16)
> > 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: -------

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



--- Comment #22 from bearophile_hugs@eml.cc 2011-09-05 16:14:07 PDT ---
(In reply to comment #21)

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

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


Andrei Alexandrescu <andrei@metalanguage.com> changed:

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


--- Comment #23 from Andrei Alexandrescu <andrei@metalanguage.com> 2011-09-05 19:11:33 PDT ---
(In reply to comment #22)
> (In reply to comment #21)
> 
> > 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: -------

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



--- Comment #24 from bearophile_hugs@eml.cc 2011-09-06 02:31:57 PDT ---
(In reply to comment #23)

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