The Death of D. (Was Tango vs Phobos)

[Sean Kelly]

Steven Schveighoffer wrote:
> "Sean Kelly" <sean at invisibleduck.org> wrote in message 
> news:g8347r$201b$1 at digitalmars.com...
>> Walter Bright wrote:
>>> Sean Kelly wrote:
>>>>> What specifically I'd like from the Tango team is explicit permission 
>>>>> for the Phobos team to go over the Tango code and be able to copy/use 
>>>>> whatever portions of it are necessary to get the two libraries to have 
>>>>> a compatible core, and to relicense those parts under the corresponding 
>>>>> Phobos license.
>>>> I think this is arguably a reasonable first step, but working towards a 
>>>> compatible core still means two separate cores, which means not being 
>>>> able to use Tango and Phobos together in the same app.  So I'll admit to 
>>>> not completely understanding the reasoning behind this approach, but 
>>>> it's the only option so I'm happy to comply.  Frankly, I don't want to 
>>>> be stuck maintaining the Tango runtime from now until doomsday anyway 
>>>> :-)
>>> If the cores are compatible at the API level, then one should be able to 
>>> mix and match Tango/Phobos user level modules.
>> I think it will turn out to be more complicated than that.  The runtime 
>> contains user-visible code as well as the compiler support code and GC: 
>> exception definitions, the thread code, etc.  And Phobos vs. Tango have 
>> different exception hierarchies, at the very least.
> 
> As far as threads, I agree.  One must be chosen.
> 
> As far as exceptions, yes, one base must be chosen, and the exceptions put 
> forth by the compiler must be chosen, but higher level exceptions do not 
> have to be part of the runtime.  For example, in Tango, socket exceptions 
> are in the same module as array bound exception (which is needed by the 
> compiler).  These should be separated if we are to have a common runtime.

This decision camw fairly late in the game, and the basic reasoning was 
that we wanted to establish a formal exception hierarchy.  So a bunch of 
relatively standard exceptions were moved into tango.core.Exception to 
populate the hierarchy.  The alternative would have been for multiple 
packages in Tango to try and declare and share a common top-level 
Exception class, and that was just too messy.  However, I think it's 
worth noting that none of the exceptions declared in tango.core are 
terribly specific.  Even SocketException is extremely broad, and as 
applicable for end users as it is for Tango itself.

For what it's worth, this is one of the few bits of the runtime that I 
didn't send to Walter because others were involved in designing the 
hierarchy.  Since there's no real code involved in exception 
declarations it was probably over-cautious of me to omit it, but I 
didn't want there to be any risk of contention later.

> And in that case, I think you can draw a clear line: what is needed to 
> compile programs, and what is needed to start the runtime.  Everything else 
> should be standard library code, and should be relegated to whatever you 
> fancy as the runtime.

Tango was designed from the start such that the runtime (that is, the 
code which is loaded invisibly for every D application) consists of 
three distinct parts:

* the compiler runtime (ie. language support code)
* the garbage collector
* some subset of the standard library which the compiler and GC code may 
depend upon

This design has some great advantages:

* People with special needs (such as kernel developers) can replace or 
stub out an entire subset of the runtime if the default version doesn't 
suit their needs
* The compiler runtime is completely separate from the other runtime 
code and may be maintained entirely separately--ie. it has no 
dependencies on standard library code
* The garbage collector is completely separate as well.  In fact, the GC 
may be chosen at link-time simply by specifying a different library. 
Tango contains two GCs to demonstrate this: one is the classic 
mark/sweep GC and the other simply calls malloc and free.

Unfortunately however, none of this gets around the issue that the 
standard library portion of the code must exist in only one location. 
And I expect that both the Phobos and Tango team have a vested interest 
in not changing how this stuff is exposed.  In the case of Tango, this 
interest is backed by the fact that we have a book in print documenting 
this stuff, which also happens to be the only English book about D that 
I'm aware of.

> I propose these essential classes and modules be moved into a separate 
> package, like std.runtime.  So you would have std.runtime.thread, 
> std.runtime.exception, etc.  Or whatever.  Then the line is even clearer.

See above.  That would be fine except for the confusion it would cause 
for readers of our book.  Also, maintenance responsibility is a 
potential issue.  None of these issues are addressed by a simple desire 
to share code.


Sean