[Issue 3813] Bad writeln of arrays

[d-bugmail at puremagic.com]

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



--- Comment #22 from bearophile_hugs at 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: -------