I was just looking through bearophile's library (which is based on Phobos) and thinking about how it's too bad that I can't use it because my code is all based on Tango.

I know there are plans currently in the works to implement a compatible runtime layer, via Sean's druntime project. And it'll be a breath of fresh air to get rid of the basic incompatibilities in the two runtimes.

But if that's all that happens, it'll still leave an undesirable situation, since all the other userland stuff will be incompatible.

Eventually, any significantly complex project is likely to have some dependent libraries built on top of both Phobos and Tango. At the very least, string-processing routines from both libraries will get compiled into the final executable.

Not only will that result in duplication of functionality (and code bloat), but it'll also mean a bunch of bit-twiddling whenever sending a Tango type into a Phobos-dependent library function (and vice versa).

Are there any plans in the works to mitigate that problem? Like, perhaps, negotiating a common API so that at least the names and argument types are the same in both libraries?

I'm sure the two libraries will always include different subsets of functionality, but whenever they implement the same basic features, it'd be great if they used a compatible API.

--benji

Hello Benji,

> I was just looking through bearophile's library (which is based on
> Phobos) and thinking about how it's too bad that I can't use it
> because my code is all based on Tango.
> 
> I know there are plans currently in the works to implement a
> compatible runtime layer, via Sean's druntime project. And it'll be a
> breath of fresh air to get rid of the basic incompatibilities in the
> two runtimes.
> 
> But if that's all that happens, it'll still leave an undesirable
> situation, since all the other userland stuff will be incompatible.
> 
> Eventually, any significantly complex project is likely to have some
> dependent libraries built on top of both Phobos and Tango. At the very
> least, string-processing routines from both libraries will get
> compiled into the final executable.
> 
> Not only will that result in duplication of functionality (and code
> bloat), but it'll also mean a bunch of bit-twiddling whenever sending
> a Tango type into a Phobos-dependent library function (and vice
> versa).
> 
> Are there any plans in the works to mitigate that problem? Like,
> perhaps, negotiating a common API so that at least the names and
> argument types are the same in both libraries?
> 
> I'm sure the two libraries will always include different subsets of
> functionality, but whenever they implement the same basic features,
> it'd be great if they used a compatible API.
> 
> --benji
> 


The first step is an incredibly important step in the right direction for now (the runtime); I'm excited to see this happening.  Many thanks to Sean, Walter, Andrei, and others for allowing this to go forward.  I'm guessing it might not be best to push for too much more as that solution is being worked out.  ;-)

Eventually, similar to other suggestions here, I was hoping that Tango could be viewed as a group of addon libraries (tango.net, tango.io, tango.util, etc), selectively available to dmd users to use at whim and easily packaged with the std compiler as an addon subdirectory (since the runtime is shared). In many respects that is exactly the current function of the Tango user packages except that these are based on the Tango runtime/core.  This is pretty much how Tangobos gets along too.  Of course, this may involve a minimal amount of merging of some shared concepts in Phobos/Tango at the core level, like you suggest; therefore, perhaps waaay in the future, this is what will have to be worked out (well... that and the need for Tango to move to D 2.0 and differences in licensing?).

But beyond that, it's not so simple as the above, I imagine, because there is the management, interpersonal, and community factors involved at the higher level that are invariably much more complicated than just merging and packaging of code.

Yep, probably best just to be content with the druntime for now... that's a big move in itself ... and a great one.  If we demand too much of these guys, they are gonna balk. :-D

-JJR

John Reimer wrote:
> Yep, probably best just to be content with the druntime for now... that's a big move in itself ... and a great one.  If we demand too much of these guys, they are gonna balk. :-D

Oh, don't get me wrong. I think it's a fantastic first step. I was just wondering whether there's a "step two" on the drawing board yet.

--benji

Benji Smith wrote:
> John Reimer wrote:
>> Yep, probably best just to be content with the druntime for now... that's a big move in itself ... and a great one.  If we demand too much of these guys, they are gonna balk. :-D
> 
> Oh, don't get me wrong. I think it's a fantastic first step. I was just wondering whether there's a "step two" on the drawing board yet.

Step one is gonna be a doozy!

Walter Bright wrote:
> Benji Smith wrote:
>> John Reimer wrote:
>>> Yep, probably best just to be content with the druntime for now... that's a big move in itself ... and a great one.  If we demand too much of these guys, they are gonna balk. :-D
>>
>> Oh, don't get me wrong. I think it's a fantastic first step. I was just wondering whether there's a "step two" on the drawing board yet.
> 
> Step one is gonna be a doozy!

And I'm sure I speak for us all when I say we *REALLY* appreciate it. Being able to use both libraries will be a huge win.

--benji

Benji Smith wrote:
> I was just looking through bearophile's library (which is based on Phobos) and thinking about how it's too bad that I can't use it because my code is all based on Tango.
> 
> I know there are plans currently in the works to implement a compatible runtime layer, via Sean's druntime project. And it'll be a breath of fresh air to get rid of the basic incompatibilities in the two runtimes.
> 
> But if that's all that happens, it'll still leave an undesirable situation, since all the other userland stuff will be incompatible.
> 
> Eventually, any significantly complex project is likely to have some dependent libraries built on top of both Phobos and Tango. At the very least, string-processing routines from both libraries will get compiled into the final executable.
> 
> Not only will that result in duplication of functionality (and code bloat), but it'll also mean a bunch of bit-twiddling whenever sending a Tango type into a Phobos-dependent library function (and vice versa).
> 
> Are there any plans in the works to mitigate that problem? Like, perhaps, negotiating a common API so that at least the names and argument types are the same in both libraries?
> 
> I'm sure the two libraries will always include different subsets of functionality, but whenever they implement the same basic features, it'd be great if they used a compatible API.
> 
> --benji


That could have some difficult aspects, but here's an uncomplicated second step: The math libraries for Tango and Phobos aren't merely compatible, they are THE SAME! They are a cut-and-paste of each other, with a couple of trivial name changes.
There are no licensing issues or personality clashes to worry about -- I've written most of both of them. They have no dependencies on anything else in either Phobos or Tango. I have write access to repositories of both Phobos and Tango.
YET -- there are two bodies of code! This is absolutely ridiculous, and it's driving me mad.

How can we turn this into ONE body of code?
It will only be possible if there is a namespace which is present in both Tango and Phobos. There are exactly three ways in which this can be done:
Either
(1) Tango needs to include part of the std namespace,
(2) Phobos needs to include part of the tango namespace, or
(3) Both need to start including a new namespace which is common to both.

Of these options, I think (2) is the least natural. For (1) to work, the modules invoved would need to be clearly designated as common.

---
Suggestion #1

The best situation I can imagine would be if Phobos started using the phobos namespace for stuff which is not common with Tango, and std was used for the common stuff.

My preferred option would be to remove tango.math.Math (stupid name anyway), combine it with tango.math.IEEE (another doubtful name) and rename it as std.math.
The more advanced math functions would remain in Tango, since I like the two-level heirachy which Tango provides. The advanced functions which are currently duplicated (eg, std.math.tgamma) would be removed from Phobos.

---

There are many other alternatives, perhaps someone will suggest a better or more acceptable alternative. I don't care, as long as I can stop having to copy & paste all my code.

Yes, lots of stuff is going to break. But I think we have to accept that. The potential gains from healing this massive schism in D are enormous.

On Mon, 13 Oct 2008 09:31:46 +0200, Don wrote:

[..]
> Suggestion #1
> 
> The best situation I can imagine would be if Phobos started using the phobos namespace for stuff which is not common with Tango, and std was used for the common stuff.
> 
> My preferred option would be to remove tango.math.Math (stupid name
> anyway), combine it with tango.math.IEEE (another doubtful name) and
> rename it as std.math.
> The more advanced math functions would remain in Tango, since I like the
> two-level heirachy which Tango provides. The advanced functions which
> are currently duplicated (eg, std.math.tgamma) would be removed from
> Phobos.
> 
> ---
> 
> There are many other alternatives, perhaps someone will suggest a better or more acceptable alternative. I don't care, as long as I can stop having to copy & paste all my code.
> 
> Yes, lots of stuff is going to break. But I think we have to accept that. The potential gains from healing this massive schism in D are enormous.

I agree that lot's of stuff is going to break
and that the benefits are big.

If a merge is ever going to happen (and I hope it does)
it has do be done today rather than tomorrow.

Here is a three step plan:
- plan the basic design concept of a new std. namespace.
- rename the current std. to phobos.
- continue to populate std from Phobos and Tango.

The main point of debate would be the structure of the new std namespace. It's hard to combine simplicity and small size have to be combined with the feature richness and speed of Tango.

On Mon, 13 Oct 2008 09:56:06 +0000, Moritz Warning wrote:

> On Mon, 13 Oct 2008 09:31:46 +0200, Don wrote:
> 
> [..]
>> My preferred option would be to remove tango.math.Math (stupid name
>> anyway), combine it with tango.math.IEEE (another doubtful name) and
>> rename it as std.math.
>> The more advanced math functions would remain in Tango, since I like
>> the two-level heirachy which Tango provides. The advanced functions
>> which are currently duplicated (eg, std.math.tgamma) would be removed
>> from Phobos.
>>

The near future is that Tango and Phobos will live next to each other because they are about to get a a common runtime.

Phobos may become a library for starting with D and people will switch to Tango further or later. Similar to the way it is already.

People who (have to?) care about the Phobos license (Public Domain) vs. Tango license (BSD style/Public Domain mix) will probably stay with Phobos.


Tango already shares quite some code with Phobos.
So it might be not that unlikely that Tango and Phobos would be bundled
along with a compiler. Phobos would then be able to redirect to Tango for
shared code.

Maybe Phobos will be dropped and Walter&staff become part of the Tango team. But that would introduces a bunch of human related problems.

Either way, things are about to get a lot better from the user perspective Time will tell.

Moritz Warning wrote:
> On Mon, 13 Oct 2008 09:56:06 +0000, Moritz Warning wrote:
> 
>> On Mon, 13 Oct 2008 09:31:46 +0200, Don wrote:
>>
>> [..]
>>> My preferred option would be to remove tango.math.Math (stupid name
>>> anyway), combine it with tango.math.IEEE (another doubtful name) and
>>> rename it as std.math.
>>> The more advanced math functions would remain in Tango, since I like
>>> the two-level heirachy which Tango provides. The advanced functions
>>> which are currently duplicated (eg, std.math.tgamma) would be removed
>>> from Phobos.
>>>
> 
> The near future is that Tango and Phobos will live next to each other because they are about to get a a common runtime.
> 
> Phobos may become a library for starting with D and people will switch to Tango further or later. Similar to the way it is already.
> 
> People who (have to?) care about the Phobos license (Public Domain) vs. Tango license (BSD style/Public Domain mix) will probably stay with Phobos.
> 
> 
> Tango already shares quite some code with Phobos.
> So it might be not that unlikely that Tango and Phobos would be bundled along with a compiler. Phobos would then be able to redirect to Tango for shared code.

> 
> Maybe Phobos will be dropped and Walter&staff become part of the Tango team. But that would introduces a bunch of human related problems.

When I look at the team for Phobos and Tango, I actually don't see that many areas where they are in direct competition.

Andrei and Bartosz seem much more interested in algorithms and stuff close to the runtime, whereas Tango has a lot of contributers with a much stronger application focus, and a huge body of code that began in Mango. It would be a monumental waste of time for Andrei to implement a HttpClient code, for example.

On Mon, 13 Oct 2008 15:12:17 +0200, Don wrote:

> Moritz Warning wrote:
>> On Mon, 13 Oct 2008 09:56:06 +0000, Moritz Warning wrote:
>> 
>>> On Mon, 13 Oct 2008 09:31:46 +0200, Don wrote:
>>>
>>> [..]
>>>> My preferred option would be to remove tango.math.Math (stupid name
>>>> anyway), combine it with tango.math.IEEE (another doubtful name) and
>>>> rename it as std.math.
>>>> The more advanced math functions would remain in Tango, since I like
>>>> the two-level heirachy which Tango provides. The advanced functions
>>>> which are currently duplicated (eg, std.math.tgamma) would be removed
>>>> from Phobos.
>>>>
>>>>
>> The near future is that Tango and Phobos will live next to each other because they are about to get a a common runtime.
>> 
>> Phobos may become a library for starting with D and people will switch to Tango further or later. Similar to the way it is already.
>> 
>> People who (have to?) care about the Phobos license (Public Domain) vs.
>> Tango license (BSD style/Public Domain mix) will probably stay with
>> Phobos.
>> 
>> 
>> Tango already shares quite some code with Phobos. So it might be not that unlikely that Tango and Phobos would be bundled along with a compiler. Phobos would then be able to redirect to Tango for shared code.
> 
> 
>> Maybe Phobos will be dropped and Walter&staff become part of the Tango team. But that would introduces a bunch of human related problems.
> 
> When I look at the team for Phobos and Tango, I actually don't see that many areas where they are in direct competition.
> 
> Andrei and Bartosz seem much more interested in algorithms and stuff close to the runtime, whereas Tango has a lot of contributers with a much stronger application focus, and a huge body of code that began in Mango. It would be a monumental waste of time for Andrei to implement a HttpClient code, for example.

Right, this diminishes friction.
Let's see what will happen.
I think things need to go step by step, without thinking about a master
plan.