D BUGS Part 2

[Andrei Alexandrescu]

bearophile wrote:
> The first part of this post was posted around October 2 2008, and 
> shows a lits of general bugs I have found in DMD/D.
> 
> This post lists several problems/bugs/limits I have found in the 
> write/writefln of D1.
[snip]

Thanks for taking the time to write them down. I was thinking you'd
write a number of actual bugs in write(f)(ln) instead of an infomercial
on put(r). Anyhow, these are good ideas that should be embodied in Phobos.

One note about the charter. I think it's slightly different.

> The purpose of such functions: to print data and data structures on 
> the console.

I disagree. The purpose is to print data and data structures to any text
device, with the console as a particular case and a potential shortcut.

> Such printing is mostly for the programmer, expecially during debug,
> or for logging.

I disagree. Printing should work equally well for "real" tasks.

> - Fast, possibly as fast as printf().

Cool.

> - Unambiguous: the printed data must clearly show the type and
> content of data.

I'm unclear on this. It would mean that if you print a short with value
1, you'd have to specify that it's a short. Or if you print a real
number valued at 1, you'd have to include the decimal point. Now I agree
that the decimal point (followed e.g. by zeros) is sometimes desirable,
but sometimes it's just not. So I'm rather confused about this
unambiguity principle.

I'd replace it with a flexibility requirement, e.g. that one can print
numbers in a variety of formats.

> - Complete: all built-ins must have a good representation.

And what happened to "Extensible: user-defined types should be able to
define their own printing." toString won't cut it!

> - Elegant and clean: to speed up the reading and have a good logs.

Great.

> - A representation: when possible it can be useful to have an
> alternative way to represent something in a more precise way. Python
> tells apart the two usages: str() and its dual __str__ return a
> readable textual representation, while repr() and __repr__ often
> return a textual representation that put inside the code generates
> the same object that has being printed. In dlibs I have found useful
> create the same pair of functions (but in D objects have only one
> toString(), so there's no support for a toRepr or something similar).

I think that's a great idea. One format for default printing, and one
precise format for serialization.

One thing that is sorely missing from this all is parsing. I think 
library functions for formatted writing must be accompanied by functions 
for formatted reading. (scanf does that for printf, but I think it's 
doing a rather awkward job.)

The presence of parsing routines changes the charter a bit, e.g. in the 
precise serialization mode you'd want to print an object in a manner 
that makes it parsable later.


Andrei