[Issue 3813] Bad writeln of arrays

Mon Sep 5 19:11:47 PDT 2011

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

Andrei Alexandrescu <andrei at metalanguage.com> changed:

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

--- Comment #23 from Andrei Alexandrescu <andrei at 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: -------