The path to unity

[Denis Koroskin]

On Sat, 07 Feb 2009 10:03:37 +0300, Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:

> Denis Koroskin wrote:
>> Well put, thank you. Everyone finds this situation annoying. That's the  
>> Number One problem of the D (remember "top five" poll?).
>>  The problem as I see it is that there is an overlapping functionality  
>> in Phobos and Tango (std.stream.Stream/tango.io.Conduit etc).
>> The solution as I see it to redesign Phobos and Tango by removing dead  
>> (buggy, unsupported) code, separating libraries functionality and  
>> removing duplication.
>>  I'd remove from Phobos:
>>  std.
>>  openrj
>>  bigint (old one, by Janice)
>>  regexp
>>  socket
>>  xml
>>  much, much more (see more complete list in my previous post[1]).
>
> These don't work all too well. But there's another issue with the  
> approach you suggest. There's no dialectics. You assume that the above  
> are the last word on the matter uttered by phobos. But things may be  
> rewritten quite a bit for D2. Speaking of your short list above, indeed  
> openrj sucks and should disappear (don't get me started). Bigint should  
> be replaced by Don's implementation. Regexp should be rewritten to use  
> ranges and templatized characters everywhere (you'd be able to read text  
> from stdin using a regexp as a separator... anyone who's tried that  
> knows that's quite a feat). Socket also needs to be rewritten to support  
> ranges. Xml too, in addition to replacing the slow delegates with fast  
> aliases. All of these should use the full power and expressiveness of  
> D2, not transport their old design to it (as they are doing now).
>

Yes, but who will do it and when? 

>> and suggest/force users use tango instead.
>>  What's left in Phobos? A fundamental part *only*:
>>  std.
>>  math (including IEEE and BigInteger) [2]
>>  range
>>  traits
>>  algorithm
>>  contracts
>>  atomics (arguably)
>>  date/time (arguably)
>
> What happened to std.random? (I just changed it to support the range  
> interface; all random generators are infinite input ranges.) And what  
> happened to the up-and-coming std.matrix, which is supposed to provide a  
> representational lingua franca for a variety of linear algebra libraries?
>

Sorry, no offense was intended. I should have put etc there.
Random and matrix belong to math category above; traits, typecons and containers are fundamental, too. Can you draw a line between general purpose and domain specific code?

I really tried to keep the list as short as possible to make stress that Phobos should be small.

>> So /any/ D compiler distribution would contain:
>> core (druntime)
>> std  (phobos)
>> tango
>>  'druntime' would provide an essential functionality to run D programs  
>> on other platforms: gc, compiler, runtime, etc.
>> std - provide simple and generic functionality, that can be used in  
>> conjunction (unix style): algorithm, range, contracts, math[2], some  
>> helpers/utils, etc.
>> tango - extended functionality: network, io (including console io),  
>> xml, etc
>>  Tango would depend on Phobos (which is now *very* tiny) and both  
>> depend on druntime. I believe Tango will greatly benefit from using  
>> contracts, ranges and algorithms, that are absent from it.
>
> I think that would be great. The way I see things, however, things like  
> ranges percolate through other parts of the library so strongly and so  
> visibly, they are bound to decisively influence a lot more than just  
> implementation internals.
>

That's true, and it is good.

>> Competition is good, but only at early stages.
>
> And then what? The Communist Utopia takes over?
>
>> Tenders/Bids are only exist to choose the best one and stick with it -  
>> the others are dropped at some point. The same thing should happen with  
>> Tango/Phobos now - inferior functionality should be dropped in favor or  
>> superior one. (It doesn't necessarily mean that either Phobos or Tango  
>> should be dropped entirely, but rather some modules - std.regexp vs.  
>> tango.text.Regex, std.socket vs tango.net.*, etc).
>
> Sure, that's great. Et que le meilleur gagne. But I'm not sure why in  
> this reasoning you suppose my gonads are empty. No. They are just busy  
> with other stuff. Conversely, consider I took your advice six months  
> ago. That means there would have been no std.algorithm, no std.range,  
> and no small but crucial language changes that made them possible  
> (notably local instantiation). My opinion of the two is that they are a  
> damn fine piece of design, and I don't even pat myself on the back  
> because much of the design isn't mine; it's Stepanov's (in concept) and  
> Walter's (in the language that allows expression of said concept). My  
> perception is that others also seem to enjoy that design. So probably  
> it's good I did /not/ take advice to drop phobos. But somehow now seems  
> to be a better moment to do so. But if I were you I'd ask, dude, you  
> mentioned containers and all that range topology stuff - anything  
> interesting coming down the pike? This is an important question, because  
> it's tied to a larger one - are Java containers the best that D2 can do?  
> And if not, how would D2's containers look like?
>

You got it all wrong. I didn't mean that once we adopt one or another code base, we don't extend it anymore. Quite the contrary. But wasting time supporting legacy code is useless.

All the stuff you write is trully awesome, I believe it is the best what is happen in history of D! All of it is of general purpose and thus should be contributed to std lib, of course.

You see, the way Phobos was created has historical background - stuff was being added to fill gaps of std library, so that there would be something to start with quickly (stream, socket, xml, etc). But unfortunately many of those modules became abandonded and a their redesign is basically impossible in D1 because it may break user code. This is awful.

What I meant is that now that we got better replacements of some Phobos functionality, why not deprecate old one and remove from Phobos, while we still have that possibility? Encourage users to use third party libraries for such functionality. That's pretty much the reson why C++ doesn't include xml, networking etc in STL. There are so many approaches to implement them that you can't please everyone.

>> Does anyone agree/disagree with me? Anyone see other solutions? Please,  
>> don't stay away from discussion.
>
> I actually plan to stay away from this discussion henceforth. I've said  
> too much already, and the first-to-last thing I need (before a bullet in  
> my head) is being drawn in a political discussion. Bottom line, I'd  
> completely agree with you if the situation was stagnant. But right now  
> it's anything but stagnant. And that changes everything.
>
>> PS. Andrei is about to finish TDPL. What does it say about Phobos,  
>> Tango and the situation around "std libraries"?
>
> What situation?
>
>> What part of Phobos does it cover? I *really* hope it doesn't say much  
>> about anything apart from std.range/algorithm/traits/contracts.
>
> I think you can rest assured that the likes of std.openrj will not be  
> mentioned :o|.
>
>
> Andrei