D BUGS Part 2

[bearophile]

Andrei Alexandrescu:

>instead of an infomercial on put(r).<

I have shown what I think is wrong, what I think is right, and I have actually written code that does that. So I'm not just asking for improvements, the code may also show how to implement them, and what practical limits D1 language gives to the implementation.
So it's a kind of "infomercial", but I think it gives more information that just a list of troubles/limits/bugs of the Phobos functions.
And I am not asking you money :-)


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

OK.


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

OK, when possible.


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

>Cool.<

But at the moment writef is quite (much) slower than printf. For put/putr speed is for me less important than the other qualities. When I need more speed I generally use printf. Creating put/putr functions almost as fast as printf is probably possible, but it may require lot of work (and some assembly too, maybe).


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

Well, in this situation I have adopted a compromise that I hope is sensible: integral numbers are printed all the same (I have given a thought about adding a trailing L to longs/ulongs when sting-fied with repr() instead of str(), but so far I have refused it. It's possible, anyway.), but FP ones are printed with a leading .0. Because telling apart FP from integrals is important enough.


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

There I was talking about default representations, the one you receive if you do just a putr(10.0).
If you don't want the leading zero, then you are supposed to have ways to not print it.

Instead putr(repr(10.0)) has to give all the digits, to represent all the bits of the original FP.


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

I like to have a good and not too much ambiguous default representation, plus a way to change representation when I want it.
put()/putr() are meant for the default representation. If you want to extend their syntax, you can take a look for example at how C#/Python3 prints formatted things.


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

There are many ways to solve this problem, but I think it may lead to a more complex language and semantics, so maybe you don't want that.
An intermediate solution may be to have the toString() object/struct method accept arguments too, that can be used by user-defined printing functions for a choice of desired representation...


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

Note that's a first approximation. It doesn't cover all possibilities, so it's not a fully flexible solution. So it's a solution that covers 80% of the cases keeping complexity low enough. So it's a compromise between complexity and flexibility. C++ language often prefers to have too much complexity to have a higher flexibility.

D language accepts less flexibility to keep its complexity low enough to be usable by humans too. And no, sometimes you can't have both: sometimes you can't have a high flexibility and low complexity. D2 language is clearly more complex than D1, and D1 is quite more complex than Java. too much complexity kills a language (or just gives lot of pain to programmers and produces bugs and slows down development, see the C++ language).


>One thing that is sorely missing from this all is parsing.<

I agree. But I was talking about printing only.


>The presence of parsing routines changes the charter a bit,<

I see, but I don't know how this changes the situation.

Bye,
bearophile