Standard Library Concerns (Phobos / Tango)

Sean Kelly sean at f4.ca
Fri Feb 8 08:12:56 PST 2008


Tim Burrell wrote:
> jcc7 wrote:
>> == Quote from Tim Burrell (tim at timburrell.net)'s article
>>> Don Clugston wrote:
>> ...
>>>> I'm working on making the mathematics of Phobos and Tango
>>>> compatible; hopefully we'll end up with a single code base.
>>> Wow that's great news!  Have you opened a discussion with the Tango
>>> devs yet?  I'm sure they'd be receptive to providing input.
>> I was under the impression that Don was one of the Tango devs. ;)
>> http://www.dsource.org/projects/tango/wiki/Contributors
> 
> Oh... haha... well scratch that then :).
> 
> The idea of a single code base is pretty enticing to me.  I was just
> trying to get a feel for how plausible it is that it might happen.

That's pretty much Tango with Tangobos in a nutshell.  If things were to
flip in the other direction, then portions of tango.core would be an
issue because they are user-visible runtime features.  Maintenance of
this code would need to be addressed, as well as the location where it's
exposed.
 It's less of a problem to run Phobos on the Tango runtime (ie.
Tangobos) because essentially all of Phobos is runtime agnostic, and the
runtime features are exposed in a much more haphazard manner (which
actually makes it easier to safely ignore them).  For example, Phobos
contains a bunch of modules in std that is actually runtime code:
std.array, std.asserterror, std.outofmemory, etc.  The user is really
supposed to actually ignore all of these modules, so there's no reason
to expose them in Tangobos at all.

If you're interested, diff Tangobos with Phobos.  I think you'll find
that the only modules with any changes at all are std.thread and
std.signals.  The rest all works basically without any changes at all.
The opposite would not be true of Tango however, because of the
additional runtime features provided and the structured manner in which
they are exposed.


Sean



More information about the Digitalmars-d mailing list