The Death of D. (Was Tango vs Phobos)

[Steven Schveighoffer]

"Sean Kelly" wrote
> 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.

I didn't mean exceptions need to be defined in individual modules, they can 
live in one file, but the user-lib exceptions need to be separate, because 
Phobos isn't going to care about Tango's SocketException for instance (or 
vice versa).

There is nothing wrong with having runtime exceptions in one module, and 
being publicly imported in the user lib's exception module (which could 
remain as tango.core.Exception).

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

I agree that Tango's runtime design makes it ideal for splitting out from 
the user code.

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

Exposure can be aliased (see below).

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

This is my view (might not work, but I think it could).  For purposes of 
simplicity, I'll assume Walter currently develops the Phobos runtime (not 
that he doesn't, but I'm really not sure :).

Maintenance of the merged runtime would become Walter's responsibility, with 
your help if necessary (ideas and help understanding, and enhancements if 
you wish).  Any changes desired for the runtime would go through Phobos (and 
Walter).  The Tango lib would use the now tango-fied Phobos runtime, with 
alias imports for existing code (e.g. tango.core.Thread would either 
publicly import std.thread or would privately import it, and alias the 
Thread class).

Phobos user lib code would do the same, although I'd suspect that since 
Walter is maintaining the runtime, he'd want to follow Phobos' package and 
naming conventions.  The one requirement for it is that the Phobos runtime 
MUST be separate from the user lib, and not depend on it.  So no calling on 
Andrei's fancy Phobos-only templates :)  This is similar to how I wanted 
Thread to use TimeSpan, but we can't because TimeSpan is part of the user 
lib.

People who have the book can still use the code and ideas presented in the 
book, because the imports will alias the real classes/structs from the new 
Phobos runtime.

BTW, since the book was released, there have been a lot of breaking changes, 
so the edge of that point is dulled quite a bit.

How does this sound (for both you and Walter)?

-Steve