www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The path to unity

reply Don <nospam nospam.com> writes:
With the druntime project, we now have a run time which is shared 
between Tango and Phobos. This is a huge step forward, but it's still 
not much use without some common user code.

The highest priorities which I see are, in order:
(1) the C standard library
tango.stdc = std.stdc
(2) low-level compiler-related modules
most of tango.core -- for the most part, this is already part of druntime.
(3) tango.math.Math + tango.math.IEEE  = std.math - tgamma().

Can we get agreement on unification of these, at least?

If we are able to reach agreement on this, I propose the next step would 
be to ensure that the contents of these files be made "identical" on 
Phobos2 and Tango. ("identical" meaning that when the Tango code is 
ported to D2, it will be identical to the Phobos2 version, except for 
module name differences).

Doing this will not give us very many immediate benefits. It will break 
a very small amount of code, but only in fairly trivial ways. In doing 
so, it will remove the subtle inconsistencies between the libraries.
 From there, the next step (quick to implement, but requiring political 
agreement <g>) would be to decide on a common namespace. Since this 
first step is much less political, I'd like to get agreement to do it now.
Feb 06 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Fri, Feb 6, 2009 at 11:05 AM, Don <nospam nospam.com> wrote:

 With the druntime project, we now have a run time which is shared between
 Tango and Phobos. This is a huge step forward, but it's still not much use
 without some common user code.

 The highest priorities which I see are, in order:
 (1) the C standard library
 tango.stdc = std.stdc
 (2) low-level compiler-related modules
 most of tango.core -- for the most part, this is already part of druntime.
 (3) tango.math.Math + tango.math.IEEE  = std.math - tgamma().

 Can we get agreement on unification of these, at least?


I agree with that.  tango.stdc.posix is also far more complete than
what is in Phobos and would be beneficial to everyone.


 If we are able to reach agreement on this, I propose the next step would be
 to ensure that the contents of these files be made "identical" on Phobos2
 and Tango. ("identical" meaning that when the Tango code is ported to D2, it
 will be identical to the Phobos2 version, except for module name
 differences).

 Doing this will not give us very many immediate benefits. It will break a
 very small amount of code, but only in fairly trivial ways. In doing so, it
 will remove the subtle inconsistencies between the libraries.
 From there, the next step (quick to implement, but requiring political
 agreement <g>) would be to decide on a common namespace. Since this first
 step is much less political, I'd like to get agreement to do it now.


Hmmmmm.  Name for a common namespace...... How about.... "common".
Feb 06 2009
next sibling parent reply grauzone <none example.net> writes:
 Hmmmmm.  Name for a common namespace...... How about.... "common".


Every time you introduce a new standard namespace, a bunch of innocent 
existing D programs might become invalid.
Feb 06 2009
next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Fri, Feb 6, 2009 at 11:54 AM, grauzone <none example.net> wrote:

 Hmmmmm.  Name for a common namespace...... How about.... "common".


 Every time you introduce a new standard namespace, a bunch of innocent
 existing D programs might become invalid.


Every time you unify two standard libraries, a bunch of innocent
existing D libraries can finally be used together.
Feb 06 2009
prev sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Sat, Feb 7, 2009 at 1:54 AM, grauzone <none example.net> wrote:

 Hmmmmm.  Name for a common namespace...... How about.... "common".


 Every time you introduce a new standard namespace, a bunch of innocent
 existing D programs might become invalid.


I do in fact have a top level package called "common" where I put a
bunch of code that is common to my various projects.   But I would
happily rename it in a heartbeat if it meant greater unification
between Phobos and Tango.  'Tis a small price to pay.

--bb
Feb 06 2009
parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Bill Baxter (wbaxter gmail.com)'s article

 On Sat, Feb 7, 2009 at 1:54 AM, grauzone <none example.net> wrote:

 Hmmmmm.  Name for a common namespace...... How about.... "common".


 Every time you introduce a new standard namespace, a bunch of innocent
 existing D programs might become invalid.


 I do in fact have a top level package called "common" where I put a
 bunch of code that is common to my various projects.   But I would
 happily rename it in a heartbeat if it meant greater unification
 between Phobos and Tango.  'Tis a small price to pay.


druntime already has "core", is there truly a need for a second top-level
namespace?
Feb 06 2009
next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Sean Kelly wrote:

 == Quote from Bill Baxter (wbaxter gmail.com)'s article

 On Sat, Feb 7, 2009 at 1:54 AM, grauzone <none example.net> wrote:

 Hmmmmm.  Name for a common namespace...... How about.... "common".


 Every time you introduce a new standard namespace, a bunch of innocent
 existing D programs might become invalid.


 I do in fact have a top level package called "common" where I put a
 bunch of code that is common to my various projects.   But I would
 happily rename it in a heartbeat if it meant greater unification
 between Phobos and Tango.  'Tis a small price to pay.


 
 druntime already has "core", is there truly a need for a second top-level
 namespace?


Agreed.  The mentioned packages (C libs + math) could even, if made part 
of druntime*, be under core.  Ie, 'core.stdc' and 'core.math'.

*I would now like to take a moment to propose that they both should in 
fact be part of druntime.  C compatibility is boasted as a feature of D, 
so the means to that end ought to be standardized (IMHO).  And math 
libraries are probably the most commonly used in the widest spectrum of 
programs.

My only concern is druntime turning into a "third stdlib."  Have to draw 
a line somewhere.

-- Chris Nicholson-Sauls
Feb 06 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Chris Nicholson-Sauls:

 My only concern is druntime turning into a "third stdlib."  Have to draw 
 a line somewhere.


The bigger core becomes, the less stuff (and code) is done in two ways in Tango
and Phobos, so I think it's good to have a larger and larger "core". This third
stdlib is the common shared one, after all :-)

Bye,
bearophile
Feb 06 2009
parent reply BCS <ao pathlink.com> writes:
Reply to bearophile,


 Chris Nicholson-Sauls:
 

 My only concern is druntime turning into a "third stdlib."  Have to
 draw a line somewhere.
 


 The bigger core becomes, the less stuff (and code) is done in two ways
 in Tango and Phobos, so I think it's good to have a larger and larger
 "core". This third stdlib is the common shared one, after all :-)
 
 Bye,
 bearophile


The only things that should go in are the things that both sides can agree 
on how to do.
Feb 06 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
BCS wrote:

 Reply to bearophile,
 

 Chris Nicholson-Sauls:


 My only concern is druntime turning into a "third stdlib."  Have to
 draw a line somewhere.


 The bigger core becomes, the less stuff (and code) is done in two ways
 in Tango and Phobos, so I think it's good to have a larger and larger
 "core". This third stdlib is the common shared one, after all :-)

 Bye,
 bearophile


 
 The only things that should go in are the things that both sides can 
 agree on how to do.
 
 


That makes it looks like a structure built on political, not technical, 
foundations. Without having thought much about it, I can say it doesn't 
quite sound right.

Andrei
Feb 06 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 That makes it looks like a structure built on political, not technical, 
 foundations. Without having thought much about it, I can say it doesn't 
 quite sound right.


Yet, in reality politics exists, and you can't just blind yourself thinking it
doesn't exists (extensive studies of failures in software and hardware have
shown that often the causes have a political root or part of a political root).
Often, even when it's not the best technically-wise solution, a "political
solution" may be good enough, and better than the less realistic alternatives
that try just to ignore that politics exists :-) The solution is often to
become better in politics, not to ignore it :-)

Bye,
bearophile
Feb 06 2009
prev sibling next sibling parent BCS <ao pathlink.com> writes:
Reply to Andrei,


 BCS wrote:
 

 The only things that should go in are the things that both sides can
 agree on how to do.
 


 That makes it looks like a structure built on political, not
 technical, foundations. Without having thought much about it, I can
 say it doesn't quite sound right.
 
 Andrei
 


I wasn't thinking political but a democratic selection system. Druntime should 
be a common base. From that, if tango and phobos can't even agree on how 
something should work, it isn't basic enough.
Feb 06 2009
prev sibling parent Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:

 BCS wrote:

 Reply to bearophile,


 Chris Nicholson-Sauls:


 My only concern is druntime turning into a "third stdlib."  Have to
 draw a line somewhere.


 The bigger core becomes, the less stuff (and code) is done in two ways
 in Tango and Phobos, so I think it's good to have a larger and larger
 "core". This third stdlib is the common shared one, after all :-)

 Bye,
 bearophile


 The only things that should go in are the things that both sides can 
 agree on how to do.


 
 That makes it looks like a structure built on political, not technical, 
 foundations. Without having thought much about it, I can say it doesn't 
 quite sound right.
 
 Andrei


The reason we have two standard libraries is almost entirely political.
Feb 06 2009
prev sibling next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Fri, Feb 6, 2009 at 3:59 PM, Sean Kelly <sean invisibleduck.org> wrote:

 == Quote from Bill Baxter (wbaxter gmail.com)'s article

 On Sat, Feb 7, 2009 at 1:54 AM, grauzone <none example.net> wrote:

 Hmmmmm.  Name for a common namespace...... How about.... "common".


 Every time you introduce a new standard namespace, a bunch of innocent
 existing D programs might become invalid.


 I do in fact have a top level package called "common" where I put a
 bunch of code that is common to my various projects.   But I would
 happily rename it in a heartbeat if it meant greater unification
 between Phobos and Tango.  'Tis a small price to pay.


 druntime already has "core", is there truly a need for a second top-level
 namespace?


The math library almost unarguably belongs in core, since it's just
giving you access to more capabilities of the processor, more or less.
 I'm just worried about the extent to which this might end up going.
stdc is already kind of pushing it; it's not really central to the
language or to runtime operation.  I'd rather not see more stuff
shoved into core that isn't core.
Feb 06 2009
next sibling parent reply Chad J <gamerchad __spam.is.bad__gmail.com> writes:
Jarrett Billingsley wrote:

 On Fri, Feb 6, 2009 at 3:59 PM, Sean Kelly <sean invisibleduck.org> wrote:

 == Quote from Bill Baxter (wbaxter gmail.com)'s article

 On Sat, Feb 7, 2009 at 1:54 AM, grauzone <none example.net> wrote:

 Hmmmmm.  Name for a common namespace...... How about.... "common".


 Every time you introduce a new standard namespace, a bunch of innocent
 existing D programs might become invalid.


 I do in fact have a top level package called "common" where I put a
 bunch of code that is common to my various projects.   But I would
 happily rename it in a heartbeat if it meant greater unification
 between Phobos and Tango.  'Tis a small price to pay.


 druntime already has "core", is there truly a need for a second top-level
 namespace?


 
 The math library almost unarguably belongs in core, since it's just
 giving you access to more capabilities of the processor, more or less.
  I'm just worried about the extent to which this might end up going.
 stdc is already kind of pushing it; it's not really central to the
 language or to runtime operation.  I'd rather not see more stuff
 shoved into core that isn't core.


I think that might be the point of the extra layer, extraneous though it
may seem.

Oh my, here comes another wall of text.

I'm beginning to see the Phobos/Tango split as a very advantageous thing
for D, even neglecting the benefits in terms of forcing the community
and designers to think of things like a modular runtime.  The split has
given us multiple ways to do things.  This could be a detriment if
you're pretty hardcore purist, but I think it's ultimately a good thing.
 It is humanistically convenient.  Rather than waging unending religious
wars we just take all paths at once and call it a day.  I'm seeing it
this way:  it is a tradeoff between having a bit of standard library
bloat and having discontent and dissent in the community.  IMO, the
latter is WAY more troublesome.  At the very least, having this
multiplicity allows us to appeal to more audiences--a thing that is good
for both us and the audiences.

And then there's the irony.  In the long run, this stuff should really
be dynamic linked to save on code space.  Some day in the future we will
ideally have a D framework that D programs can rely on.  It's kind of
like the .NET framework except nicer and without the added annoyance to
the user.  On Linux we have these package managers, so you can rig it so
that whenever someone installs a D program then the framework is
automatically installed once-and-for-all and all subsequent D programs
will just reuse that framework and thus be compact and efficient.  For
systems where the D framework can't be counted on (Windows), we are back
to square one where you static link against only what is needed for your
program.  That's just the cost of an inflexible OS.  If Windows ever
wants to solve the problem of carrying around massive amounts of
redundant code, then it will have to adopt a package manager.  So
ultimately the cost of redundant functionality in the standard/common
library approaches insignificance as technology progresses.

The only long term cost then is the duplication of developer effort.  I
feel that as long as this is kept reasonable, it will be proportional to
the cost of dissatisfaction, lack of evolution, lack of innovation, etc
that comes from not trying new paths and experimenting.  Humans are not
ideal creatures.  They are not homogeneous nor are they omniscient.
They do not have the ability to just look at a problem or a lack of code
and just see the full optimal solution in crystal clarity in an instant
and with %100 guaranteed effectiveness.   In these less than ideal
conditions that we are stuck with, duplicating effort may very well be
the optimal path.  A number of people will do one thing slightly
differently, and in all likelihood one of those people will get it right.

So yeah, I'm starting to warm to this idea of forever having multiple
"standard" libraries for D, and building them on top of even more
fundamental stuff.  Fundamental stuff that people won't disagree about.
 It's a good balance between forcibly unifying EVERYTHING or allowing
unfettered duplication.


- Chad
Feb 06 2009
parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Fri, Feb 6, 2009 at 6:53 PM, Chad J
<gamerchad __spam.is.bad__gmail.com> wrote:

 Oh my, here comes another wall of text.

 I'm beginning to see the Phobos/Tango split as a very advantageous thing
 for D, even neglecting the benefits in terms of forcing the community
 and designers to think of things like a modular runtime.  The split has
 given us multiple ways to do things.  This could be a detriment if
 you're pretty hardcore purist, but I think it's ultimately a good thing.
  It is humanistically convenient.  Rather than waging unending religious
 wars we just take all paths at once and call it a day.  I'm seeing it
 this way:  it is a tradeoff between having a bit of standard library
 bloat and having discontent and dissent in the community.  IMO, the
 latter is WAY more troublesome.  At the very least, having this
 multiplicity allows us to appeal to more audiences--a thing that is good
 for both us and the audiences.

 And then there's the irony.  In the long run, this stuff should really
 be dynamic linked to save on code space.  Some day in the future we will
 ideally have a D framework that D programs can rely on.  It's kind of
 like the .NET framework except nicer and without the added annoyance to
 the user.  On Linux we have these package managers, so you can rig it so
 that whenever someone installs a D program then the framework is
 automatically installed once-and-for-all and all subsequent D programs
 will just reuse that framework and thus be compact and efficient.  For
 systems where the D framework can't be counted on (Windows), we are back
 to square one where you static link against only what is needed for your
 program.  That's just the cost of an inflexible OS.  If Windows ever
 wants to solve the problem of carrying around massive amounts of
 redundant code, then it will have to adopt a package manager.  So
 ultimately the cost of redundant functionality in the standard/common
 library approaches insignificance as technology progresses.

 The only long term cost then is the duplication of developer effort.  I
 feel that as long as this is kept reasonable, it will be proportional to
 the cost of dissatisfaction, lack of evolution, lack of innovation, etc
 that comes from not trying new paths and experimenting.  Humans are not
 ideal creatures.  They are not homogeneous nor are they omniscient.
 They do not have the ability to just look at a problem or a lack of code
 and just see the full optimal solution in crystal clarity in an instant
 and with %100 guaranteed effectiveness.   In these less than ideal
 conditions that we are stuck with, duplicating effort may very well be
 the optimal path.  A number of people will do one thing slightly
 differently, and in all likelihood one of those people will get it right.

 So yeah, I'm starting to warm to this idea of forever having multiple
 "standard" libraries for D, and building them on top of even more
 fundamental stuff.  Fundamental stuff that people won't disagree about.
  It's a good balance between forcibly unifying EVERYTHING or allowing
 unfettered duplication.


I'll have to say that I wholeheartedly disagree.  (You knew this was coming.)

Even if they use a common runtime and small common core, nothing is
compatible between the user portions of the libraries. Sure, you'll be
able to install Phobos and Tango side-by-side without issue, but
honestly, why would you want to do that? Oh, I see - you're using two
third-party libraries, one based on Tango and one on Phobos. But.. it
still doesn't solve the problem. The one library wants std.date.Dates
and the other wants tango.time.Time.Times. Or std.stream.Streams vs.
tango.io.Conduits. The split between the libraries has just moved from
the runtime level up to the user level. Even if they use the same
runtime, Phobos and Tango cannot be used with one another.

Newbs are confused when they first come to the language and find out
there are two standard libraries, and that they have to choose which
one to use.  Worse, if you use one standard library, there's a whole
set of third-party libraries that you just can't use.  The alternative
is for library writers to support both libraries by writing a
compatibility layer - their own standard library! This is just
ridiculous. Not only do D users have to deal with the first-order
problem of which standard library they should use, but they also have
to deal with the second-order problem of which third-party libraries
support which standard library.

It doesn't matter how you sugarcoat it.  It doesn't give people
choices, it gives people _a_ choice - which "version" of D they want
to use: Phobos D or Tango D.  As a library writer, I can't say that I
find that situation, or the idea of writing a compatibility layer for
all but the simplest of functionality, very attractive.
Feb 06 2009
next sibling parent reply Chad J <gamerchad __spam.is.bad__gmail.com> writes:
Jarrett Billingsley wrote:

 On Fri, Feb 6, 2009 at 6:53 PM, Chad J
 <gamerchad __spam.is.bad__gmail.com> wrote:

 another wall of text.


 
 I'll have to say that I wholeheartedly disagree.  (You knew this was coming.)
 
 Even if they use a common runtime and small common core, nothing is
 compatible between the user portions of the libraries. Sure, you'll be
 able to install Phobos and Tango side-by-side without issue, but
 honestly, why would you want to do that? Oh, I see - you're using two
 third-party libraries, one based on Tango and one on Phobos. But.. it
 still doesn't solve the problem. The one library wants std.date.Dates
 and the other wants tango.time.Time.Times. Or std.stream.Streams vs.
 tango.io.Conduits. The split between the libraries has just moved from
 the runtime level up to the user level. Even if they use the same
 runtime, Phobos and Tango cannot be used with one another.
 


But they CAN be used together, Tangobos style.  There is one bad problem
with exclusive features like IO handling tripping over each other a bit.
 That is annoying.

The other possible issue is when passing types between the user level
and the third party lib: which std lib type to use?  I'd like to know
just how often std lib types are used in library interfaces.  I suspect
it's almost never.  Even then, it wouldn't stop compilation if you have
something like Tangobos.


 Newbs are confused when they first come to the language and find out
 there are two standard libraries, and that they have to choose which
 one to use.  Worse, if you use one standard library, there's a whole
 set of third-party libraries that you just can't use.  The alternative
 is for library writers to support both libraries by writing a
 compatibility layer - their own standard library! This is just
 ridiculous. Not only do D users have to deal with the first-order
 problem of which standard library they should use, but they also have
 to deal with the second-order problem of which third-party libraries
 support which standard library.
 
 It doesn't matter how you sugarcoat it.  It doesn't give people
 choices, it gives people _a_ choice - which "version" of D they want
 to use: Phobos D or Tango D.  As a library writer, I can't say that I
 find that situation, or the idea of writing a compatibility layer for
 all but the simplest of functionality, very attractive.


I do agree that this situation sucks.  Library writers need to be able
to pick one and be confident that people who prefer the other library
will still be able to use their code and with no odd quirks or gotchas
either.  This is why I see the two standard libraries becoming
completely non-exclusive, thus allowing programs to link against and use
both at the same time.
Feb 06 2009
parent John Reimer <terminal.node gmail.com> writes:
Hello Chad,


 Jarrett Billingsley wrote:
 

 On Fri, Feb 6, 2009 at 6:53 PM, Chad J
 <gamerchad __spam.is.bad__gmail.com> wrote:

 another wall of text.
 


 I'll have to say that I wholeheartedly disagree.  (You knew this was
 coming.)
 
 Even if they use a common runtime and small common core, nothing is
 compatible between the user portions of the libraries. Sure, you'll
 be able to install Phobos and Tango side-by-side without issue, but
 honestly, why would you want to do that? Oh, I see - you're using two
 third-party libraries, one based on Tango and one on Phobos. But.. it
 still doesn't solve the problem. The one library wants std.date.Dates
 and the other wants tango.time.Time.Times. Or std.stream.Streams vs.
 tango.io.Conduits. The split between the libraries has just moved
 from the runtime level up to the user level. Even if they use the
 same runtime, Phobos and Tango cannot be used with one another.
 


 But they CAN be used together, Tangobos style.  There is one bad
 problem
 with exclusive features like IO handling tripping over each other a
 bit.
 That is annoying.
 The other possible issue is when passing types between the user level
 and the third party lib: which std lib type to use?  I'd like to know
 just how often std lib types are used in library interfaces.  I
 suspect it's almost never.  Even then, it wouldn't stop compilation if
 you have something like Tangobos.
 

 Newbs are confused when they first come to the language and find out
 there are two standard libraries, and that they have to choose which
 one to use.  Worse, if you use one standard library, there's a whole
 set of third-party libraries that you just can't use.  The
 alternative is for library writers to support both libraries by
 writing a compatibility layer - their own standard library! This is
 just ridiculous. Not only do D users have to deal with the
 first-order problem of which standard library they should use, but
 they also have to deal with the second-order problem of which
 third-party libraries support which standard library.
 
 It doesn't matter how you sugarcoat it.  It doesn't give people
 choices, it gives people _a_ choice - which "version" of D they want
 to use: Phobos D or Tango D.  As a library writer, I can't say that I
 find that situation, or the idea of writing a compatibility layer for
 all but the simplest of functionality, very attractive.
 


 I do agree that this situation sucks.  Library writers need to be able
 to pick one and be confident that people who prefer the other library
 will still be able to use their code and with no odd quirks or gotchas
 either.  This is why I see the two standard libraries becoming
 completely non-exclusive, thus allowing programs to link against and
 use both at the same time.
 



If I may speak bluntly, the idea of having two "standard" libraries is
practically 
an oxymoron.  Furthermore, by definition a standard library is meant, at 
least to some extent, to enforce some sort of stricture on style and format 
of a language usually in the interest of elegance, power, and efficiency: 
such things will never appeal to everyone, although the designer of it hopes 
that his contribution will be attractive and useful to most.  Furthermore, 
every language and library carries with it a intrinsic message of "correctness" 
and "truth".  There should be no pretense that it delivers the ultimate
unification 
of all paths or that it is absent of any so-called "religion" (I still continue 
to be a little suprised whenever I read this in D's mission statement).  


Tango and Phobos are direct demonstrations of different ideals about what 
D should represent.  There is no real escaping this conflict with feathery 
thoughts about everything and everybody being able to work together.  Well... 
I should say, one can think this way, but it won't make the problems go away 
because the social and political aspects of these things are often more
influential 
than the technical.   It is possible to redefine a problem out of existance, 
but it's generally a very unsafe thing to do.


So... I don't know how adopting multiplicity in terms of the "standard" library 
can be convenient.  If you want multiplicity, developers should already have 
that option in third party libraries, a place where the choice should remain 
to avoid conflict with a language's central goals.


I think D's biggest problems have always been poor management of its social 
and political aspects.  These problems inevitably develop wherever a group 
of people gather.  This is one reason why Tango appeared in the first place. 
 That said, managing those aspects are some of the hardest things to do in 
any endeavor... perhaps because this inevitably means, at some point, you 
have to step on someone's toes.


-JJR
Feb 06 2009
prev sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Sat, 07 Feb 2009 04:43:05 +0300, Jarrett Billingsley
<jarrett.billingsley gmail.com> wrote:


 On Fri, Feb 6, 2009 at 6:53 PM, Chad J
 <gamerchad __spam.is.bad__gmail.com> wrote:

 Oh my, here comes another wall of text.

 I'm beginning to see the Phobos/Tango split as a very advantageous thing
 for D, even neglecting the benefits in terms of forcing the community
 and designers to think of things like a modular runtime.  The split has
 given us multiple ways to do things.  This could be a detriment if
 you're pretty hardcore purist, but I think it's ultimately a good thing.
  It is humanistically convenient.  Rather than waging unending religious
 wars we just take all paths at once and call it a day.  I'm seeing it
 this way:  it is a tradeoff between having a bit of standard library
 bloat and having discontent and dissent in the community.  IMO, the
 latter is WAY more troublesome.  At the very least, having this
 multiplicity allows us to appeal to more audiences--a thing that is good
 for both us and the audiences.

 And then there's the irony.  In the long run, this stuff should really
 be dynamic linked to save on code space.  Some day in the future we will
 ideally have a D framework that D programs can rely on.  It's kind of
 like the .NET framework except nicer and without the added annoyance to
 the user.  On Linux we have these package managers, so you can rig it so
 that whenever someone installs a D program then the framework is
 automatically installed once-and-for-all and all subsequent D programs
 will just reuse that framework and thus be compact and efficient.  For
 systems where the D framework can't be counted on (Windows), we are back
 to square one where you static link against only what is needed for your
 program.  That's just the cost of an inflexible OS.  If Windows ever
 wants to solve the problem of carrying around massive amounts of
 redundant code, then it will have to adopt a package manager.  So
 ultimately the cost of redundant functionality in the standard/common
 library approaches insignificance as technology progresses.

 The only long term cost then is the duplication of developer effort.  I
 feel that as long as this is kept reasonable, it will be proportional to
 the cost of dissatisfaction, lack of evolution, lack of innovation, etc
 that comes from not trying new paths and experimenting.  Humans are not
 ideal creatures.  They are not homogeneous nor are they omniscient.
 They do not have the ability to just look at a problem or a lack of code
 and just see the full optimal solution in crystal clarity in an instant
 and with %100 guaranteed effectiveness.   In these less than ideal
 conditions that we are stuck with, duplicating effort may very well be
 the optimal path.  A number of people will do one thing slightly
 differently, and in all likelihood one of those people will get it  
 right.

 So yeah, I'm starting to warm to this idea of forever having multiple
 "standard" libraries for D, and building them on top of even more
 fundamental stuff.  Fundamental stuff that people won't disagree about.
  It's a good balance between forcibly unifying EVERYTHING or allowing
 unfettered duplication.


 I'll have to say that I wholeheartedly disagree.  (You knew this was  
 coming.)

 Even if they use a common runtime and small common core, nothing is
 compatible between the user portions of the libraries. Sure, you'll be
 able to install Phobos and Tango side-by-side without issue, but
 honestly, why would you want to do that? Oh, I see - you're using two
 third-party libraries, one based on Tango and one on Phobos. But.. it
 still doesn't solve the problem. The one library wants std.date.Dates
 and the other wants tango.time.Time.Times. Or std.stream.Streams vs.
 tango.io.Conduits. The split between the libraries has just moved from
 the runtime level up to the user level. Even if they use the same
 runtime, Phobos and Tango cannot be used with one another.

 Newbs are confused when they first come to the language and find out
 there are two standard libraries, and that they have to choose which
 one to use.  Worse, if you use one standard library, there's a whole
 set of third-party libraries that you just can't use.  The alternative
 is for library writers to support both libraries by writing a
 compatibility layer - their own standard library! This is just
 ridiculous. Not only do D users have to deal with the first-order
 problem of which standard library they should use, but they also have
 to deal with the second-order problem of which third-party libraries
 support which standard library.

 It doesn't matter how you sugarcoat it.  It doesn't give people
 choices, it gives people _a_ choice - which "version" of D they want
 to use: Phobos D or Tango D.  As a library writer, I can't say that I
 find that situation, or the idea of writing a compatibility layer for
 all but the simplest of functionality, very attractive.


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

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)

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.

Competition is good, but only at early stages. 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).

Does anyone agree/disagree with me? Anyone see other solutions? Please, don't
stay away from discussion.

PS. Andrei is about to finish TDPL. What does it say about Phobos, Tango and
the situation around "std libraries"?
What part of Phobos does it cover? I *really* hope it doesn't say much about
anything apart from std.range/algorithm/traits/contracts.

---
[1] http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=82553
Please, read it if you didn't yet.

[2] 'math' is a common but not an essential to run HelloWorld so should be
moved to std; tango removes tango.math entirely and uses std.math instead. No
'common' namespace would be needed as it is Phobos/std which is 'common'.
Feb 06 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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).


 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?


 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.


 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?


 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
Feb 06 2009
next sibling parent reply Don <nospam nospam.com> writes:
Andrei Alexandrescu 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).


Seriously, if we could drop those (especially, openrj), the situation 
would be considerably improved. Much of the initial driving force for 
the creation of Tango was a feeling that Phobos was a random accretion 
of functionality, including some modules with no justification for 
inclusion in a small standard library.


 '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 for sure. But if Phobos2 were purged, it'd be a lot more 
impressive. Right now it really isn't suitable for building an extended 
library around. But after stripping out the detritus, the statements 
along the lines of "Tango will *never* be based on Phobos" might disappear.

openrj must die.
Feb 07 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Don wrote:

 openrj must die.


Check this out:

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=77296

What I wanted was to put that pet module to sleep. My request was met 
with a thundering silence. It seems like _I_ could say "You ALL ignore 
my post!"


Andrei
Feb 07 2009
next sibling parent Moritz Warning <moritzwarning web.de> writes:
On Sat, 07 Feb 2009 06:38:09 -0800, Andrei Alexandrescu wrote:


 Don wrote:

 openrj must die.


 
 Check this out:
 
 http://www.digitalmars.com/webnews/newsgroups.php?


art_group=digitalmars.D&article_id=77296

 
 What I wanted was to put that pet module to sleep. My request was met
 with a thundering silence. It seems like _I_ could say "You ALL ignore
 my post!"
 
 
 Andrei


Nobody cried, nobody objected.
Agreement without noise. :)
Feb 07 2009
prev sibling next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Andrei Alexandrescu wrote:

 Don wrote:

 openrj must die.


 
 Check this out:
 
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmar
.D&article_id=77296 
 
 
 What I wanted was to put that pet module to sleep. My request was met 
 with a thundering silence. It seems like _I_ could say "You ALL ignore 
 my post!"
 
 
 Andrei


Exactly. So... get rid of it :-)!
Feb 07 2009
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Andrei Alexandrescu wrote:

 Don wrote:

 openrj must die.


 
 Check this out:
 
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmar
.D&article_id=77296 
 
 
 What I wanted was to put that pet module to sleep. My request was met 
 with a thundering silence. It seems like _I_ could say "You ALL ignore 
 my post!"


My best posts are often met with silence.  Consider it approval ;-)


Sean
Feb 07 2009
prev sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Sat, Feb 7, 2009 at 11:38 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Don wrote:

 openrj must die.


 Check this out:

 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=77296

 What I wanted was to put that pet module to sleep. My request was met with a
 thundering silence. It seems like _I_ could say "You ALL ignore my post!"


What's the problem?  You asked who was using it, and everyone who was
using it replied.  :-)

(And what does the Andy Warhol of file formats mean anyway?  Something
about "15 minutes of fame"?)

--bb
Feb 07 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 On Sat, Feb 7, 2009 at 11:38 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Don wrote:

 openrj must die.


 Check this out:

 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=77296

 What I wanted was to put that pet module to sleep. My request was met with a
 thundering silence. It seems like _I_ could say "You ALL ignore my post!"


 
 What's the problem?  You asked who was using it, and everyone who was
 using it replied.  :-)
 
 (And what does the Andy Warhol of file formats mean anyway?  Something
 about "15 minutes of fame"?)


No, but about "famous because it claims it's famous". (It did work for 
Warhol though.) Very few actually use openrj, and of the five users 
generously featured on the openrj homepage, no less than four (sic!) are 
self-references (uses of the author himself).

Andrei
Feb 07 2009
prev sibling next sibling parent John Reimer <terminal.node gmail.com> writes:
Hello Andrei,


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

 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?
 

 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.
 

 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?
 

 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
 



Well, the funny thing is that you've effectively said more here than you 
usually do about the issue, and I think that's good. :)


It helped that you expressed plainly what you think needs fixing in Phobos. 
  Your range and algorithm work do look quite good, and you seem committed 
to the task of improving D.  These are all good signs, and I think a lot 
of people here are indeed thankful for what you are doing and what you have 
done.


I fully understand the community's discomfort in waiting for some sort of 
resolution to occur  (although I guess it's getting tedious to hear it so 
oft repeated).   If there are things that can be fixed/merged/shared between 
the two libraries, I suppose it would be good to work towards that at minimum. 
 The exchange of emails between you and Don would be very good. :)


I think it's fair to say that some things will never merge, and shouldn't 
given their different design philosophies.  But that shouldn't remove any 
hope of exchanging quality contributions between the two.  It is still my 
wish to see Tango turn into a kind of "third" party library such that its 
core is no longer necessary.  Maybe this is what druntime can do for it... 
and maybe this means integrating more things in core.  I don't know.  But 
I'm certainly game to see something happen.


-JJR
Feb 07 2009
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Sat, 07 Feb 2009 10:03:37 +0300, Andrei Alexandrescu
<SeeWebsiteForEmail 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
Feb 07 2009
prev sibling next sibling parent reply grauzone <none example.net> writes:
 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]).
 
 and suggest/force users use tango instead.


std.
   zip
   signals
   outbuffer (there isn't even inbuffer, whee)
   boxer (I like it, but Variant seems to supersede it)
   cover (highly compiler specific, why is it in the stdlib?)

Also, the following modules really belong into core:

std.
   atomics (contains intrinsics for atomic asm instructions, right?)
   intrinsics
   variant (come on!)
   complex
   bind
   bigint

Next steps:
- unify the C import modules
- move modules like std.range into core (magically enables Tango to use it)
- find a common I/O API (and put it into core), which wraps Tango/Phobos 
specific I/O APIs (personally, I'd prefer having something simple like 
std.stream [without the interfaces], instead of the clusterfuck in Tango)

PS: It's fine if it's a third stdlib, as long as both Tango and Phobos 
people agree on it. It's too late anyway, and important, user-visible 
types like Thread are in core.
Feb 07 2009
next sibling parent reply Don <nospam nospam.com> writes:
grauzone wrote:

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

 and suggest/force users use tango instead.


 
 std.
   zip
   signals
   outbuffer (there isn't even inbuffer, whee)
   boxer (I like it, but Variant seems to supersede it)
   cover (highly compiler specific, why is it in the stdlib?)
 
 Also, the following modules really belong into core:
 
 std.
   atomics (contains intrinsics for atomic asm instructions, right?)
   intrinsics
   variant (come on!)
   complex
   bind
   bigint


For bigint, only the low-level O(n^2) functions, I think. A bigint 
implementation might use O(n lg n) fourier transforms for multiply when 
the numbers get big enough -- that's far too heavyweight for the core, I 
think. The low-level functions are almost intrinsics -- bigint add is 
essentially the "add-with-carry" instruction, for example.

Also std.cpuid (without toString()).

All those modules (except complex, maybe) are things which you'd have to 
rewrite when creating a new compiler, so I think using core for them is 
reasonable.


 Next steps:
 - unify the C import modules
 - move modules like std.range into core (magically enables Tango to use it)


I think you'll find Tango eventually wants to use most of the new Phobos 
  -- you'd find everything in std gets moved into core! So I don't think 
range belongs there (unless the range struct gets built into the compiler).


 - find a common I/O API (and put it into core), which wraps Tango/Phobos 
 specific I/O APIs (personally, I'd prefer having something simple like 
 std.stream [without the interfaces], instead of the clusterfuck in Tango)
 
 PS: It's fine if it's a third stdlib, as long as both Tango and Phobos 
 people agree on it. It's too late anyway, and important, user-visible 
 types like Thread are in core.


The I/O is difficult. I think it's a legitimate design difference 
between Tango and Phobos -- we're probably stuck with it. I think it'd 
be better to leave it aside, and concentrate on unifying the simple stuff.
Feb 07 2009
parent reply Christopher Wright <dhasenan gmail.com> writes:
Don wrote:

 The I/O is difficult. I think it's a legitimate design difference 
 between Tango and Phobos -- we're probably stuck with it. I think it'd 
 be better to leave it aside, and concentrate on unifying the simple stuff.


It would be convenient if a shared low-level IO api could be used, so 
you don't get output ordering issues. However, that would probably have 
a significant performance impact.
Feb 07 2009
parent Sean Kelly <sean invisibleduck.org> writes:
Christopher Wright wrote:

 Don wrote:

 The I/O is difficult. I think it's a legitimate design difference 
 between Tango and Phobos -- we're probably stuck with it. I think it'd 
 be better to leave it aside, and concentrate on unifying the simple 
 stuff.


 
 It would be convenient if a shared low-level IO api could be used, so 
 you don't get output ordering issues. However, that would probably have 
 a significant performance impact.


There's always the C API, though I don't see the Tango library moving 
away from platform-specific routines, since they're more performant.


Sean
Feb 07 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
grauzone wrote:

 Next steps:
 - unify the C import modules


We already plan to do that in Phobos.


 - move modules like std.range into core (magically enables Tango to use it)
 - find a common I/O API (and put it into core), which wraps Tango/Phobos 
 specific I/O APIs (personally, I'd prefer having something simple like 
 std.stream [without the interfaces], instead of the clusterfuck in Tango)


You see, that's exactly the kind of rhetoric that is unlikely to bring 
any good to anyone. My understanding is that many people like Tango's 
I/O facilities and use them for real work with good results. My belief 
is that a significantly better design can be put forth in D2, but that's 
just that - a belief. Even if said belief actually materializes one day, 
I have no doubt some people would still prefer Tango's I/O. You just 
can't please everybody.

Also, my personal opinion about std.stream is that it's the typical 
product of an intermediate designer (and I hope enough time has passed 
that the original designers wouldn't take offense): it works, but it's 
baroque, repetitive, bloated, emphasizes the trivial, brings no 
particular insight, draws abstraction lines juuust a tad oblique from 
the right places, and overall leaves the slate ungainly occupied. I 
would gladly remove std.stream from phobos.


 PS: It's fine if it's a third stdlib, as long as both Tango and Phobos 
 people agree on it. It's too late anyway, and important, user-visible 
 types like Thread are in core.


Oh, threads are another big topic. D2's threading model will be probably 
the most disruptive of all of D2 and will in all likelihood render many 
thread-related parts in all libraries obsolete.


Andrei
Feb 07 2009
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Denis Koroskin wrote:

 
 Tango would depend on Phobos (which is now *very* tiny) and both depend 
 on druntime.


If you could convince the Tango folks to depend on Phobos, regardless of 
what it contains, well... I'd be surprised.


Sean
Feb 07 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Sean Kelly wrote:

 Denis Koroskin wrote:

 Tango would depend on Phobos (which is now *very* tiny) and both 
 depend on druntime.


 
 If you could convince the Tango folks to depend on Phobos, regardless of 
 what it contains, well... I'd be surprised.


Why? Any possible political motivation is long gone, and there must be 
/some/ amount of view sharing.

Andrei
Feb 07 2009
parent Sean Kelly <sean invisibleduck.org> writes:
Andrei Alexandrescu wrote:

 Sean Kelly wrote:

 Denis Koroskin wrote:

 Tango would depend on Phobos (which is now *very* tiny) and both 
 depend on druntime.


 If you could convince the Tango folks to depend on Phobos, regardless 
 of what it contains, well... I'd be surprised.


 
 Why? Any possible political motivation is long gone, and there must be 
 /some/ amount of view sharing.


That just seemed to be the general mood, historically.  But I certainly 
don't want to put words in anyone's mouth.  If this happens then I'll be 
pleased.


Sean
Feb 07 2009
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s article

 On Fri, Feb 6, 2009 at 3:59 PM, Sean Kelly <sean invisibleduck.org> wrote:

 druntime already has "core", is there truly a need for a second top-level
 namespace?


 The math library almost unarguably belongs in core, since it's just
 giving you access to more capabilities of the processor, more or less.
  I'm just worried about the extent to which this might end up going.
 stdc is already kind of pushing it; it's not really central to the
 language or to runtime operation.  I'd rather not see more stuff
 shoved into core that isn't core.


stdc is only in core because some of the core modules use it in some
indirect manner, and so the imports have to at least be available.  The
alternative would be to define this stuff directly in the relevant module,
but that would mean a lot of platform-specific code in version blocks
for one or two modules (such as core.thread).  The alternative would
be some sort of "pimpl" approach to hide these imports entirely, but
yuck.


Sean
Feb 06 2009
prev sibling parent reply "Joel C. Salomon" <joelcsalomon gmail.com> writes:
Sean Kelly wrote:

 druntime already has "core", is there truly a need for a second top-level
 namespace?


Recalling the kerfuffle over “toe”, how about a namespace “rind”? ☺

—Joel Salomon
Feb 07 2009
parent reply Sean Kelly <sean invisibleduck.org> writes:
Joel C. Salomon wrote:

 Sean Kelly wrote:

 druntime already has "core", is there truly a need for a second top-level
 namespace?


 
 Recalling the kerfuffle over “toe”, how about a namespace “rind”? ☺


That name's the pits!
Feb 07 2009
parent reply Brad Roberts <braddr puremagic.com> writes:
Sean Kelly wrote:

 Joel C. Salomon wrote:

 Sean Kelly wrote:

 druntime already has "core", is there truly a need for a second
 top-level
 namespace?


 Recalling the kerfuffle over “toe”, how about a namespace “rind”? ☺


 
 That name's the pits!


Are we gonna have to shell out for some market research?
Feb 07 2009
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Brad Roberts wrote:

 Sean Kelly wrote:

 Joel C. Salomon wrote:

 Sean Kelly wrote:

 druntime already has "core", is there truly a need for a second
 top-level
 namespace?


 Recalling the kerfuffle over “toe”, how about a namespace “rind”? ☺


 That name's the pits!


 
 Are we gonna have to shell out for some market research?
 


I say we just call it "bacon" and be done with it.  Everyone loves bacon!

Well, except for those vegetarians and vegans.  But they are strange and
terrifying because they're different...

:P

  -- Daniel
Feb 07 2009
prev sibling parent Chris R Miller <lordsauronthegreat gmail.com> writes:
Jarrett Billingsley wrote:

 On Fri, Feb 6, 2009 at 11:05 AM, Don<nospam nospam.com>  wrote:

 With the druntime project, we now have a run time which is shared between
 Tango and Phobos. This is a huge step forward, but it's still not much use
 without some common user code.

 The highest priorities which I see are, in order:
 (1) the C standard library
 tango.stdc = std.stdc
 (2) low-level compiler-related modules
 most of tango.core -- for the most part, this is already part of druntime.
 (3) tango.math.Math + tango.math.IEEE  = std.math - tgamma().

 Can we get agreement on unification of these, at least?


 I agree with that.  tango.stdc.posix is also far more complete than
 what is in Phobos and would be beneficial to everyone.


 If we are able to reach agreement on this, I propose the next step would be
 to ensure that the contents of these files be made "identical" on Phobos2
 and Tango. ("identical" meaning that when the Tango code is ported to D2, it
 will be identical to the Phobos2 version, except for module name
 differences).

 Doing this will not give us very many immediate benefits. It will break a
 very small amount of code, but only in fairly trivial ways. In doing so, it
 will remove the subtle inconsistencies between the libraries.
  From there, the next step (quick to implement, but requiring political
 agreement<g>) would be to decide on a common namespace. Since this first
 step is much less political, I'd like to get agreement to do it now.


 Hmmmmm.  Name for a common namespace...... How about.... "common".


I was thinking about keeping it simple.

Either migrate tango to std (and keep module aliases for tango for a 
while to help give people some leniency while they update their code) or 
perhaps move the whole mess to a new namespace: d (duh!)

Just my $0.02 on that subject...
Feb 06 2009
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Don wrote:

 With the druntime project, we now have a run time which is shared 
 between Tango and Phobos. This is a huge step forward, but it's still 
 not much use without some common user code.
 
 The highest priorities which I see are, in order:
 (1) the C standard library
 tango.stdc = std.stdc


druntime has this in core.stdc and core.sys.posix.  It isn't built into 
a library right now (or used by Phobos2), but this will likely change 
before too long.


Sean
Feb 06 2009
prev sibling parent reply Don <nospam nospam.com> writes:
Don wrote:

 With the druntime project, we now have a run time which is shared 
 between Tango and Phobos. This is a huge step forward, but it's still 
 not much use without some common user code.
 
 The highest priorities which I see are, in order:
 (1) the C standard library
 tango.stdc = std.stdc
 (2) low-level compiler-related modules
 most of tango.core -- for the most part, this is already part of druntime.
 (3) tango.math.Math + tango.math.IEEE  = std.math - tgamma().
 
 Can we get agreement on unification of these, at least?
 
 If we are able to reach agreement on this, I propose the next step would 
 be to ensure that the contents of these files be made "identical" on 
 Phobos2 and Tango. ("identical" meaning that when the Tango code is 
 ported to D2, it will be identical to the Phobos2 version, except for 
 module name differences).


Please read it again. I'm not asking the question "where do we put it?"
Rather, to agree that it WILL eventually go SOMEWHERE. If we agree on 
that, there are immediate implications. Those modules have some 
functions which differ in naming (mostly in case). That's a difference 
we can fix right now without the politics.
Feb 06 2009
next sibling parent reply Piotrek <starpit tlen.pl> writes:
Don pisze:

 Don wrote:

 With the druntime project, we now have a run time which is shared 
 between Tango and Phobos. This is a huge step forward, but it's still 
 not much use without some common user code.

 The highest priorities which I see are, in order:
 (1) the C standard library
 tango.stdc = std.stdc
 (2) low-level compiler-related modules
 most of tango.core -- for the most part, this is already part of 
 druntime.
 (3) tango.math.Math + tango.math.IEEE  = std.math - tgamma().

 Can we get agreement on unification of these, at least?

 If we are able to reach agreement on this, I propose the next step 
 would be to ensure that the contents of these files be made 
 "identical" on Phobos2 and Tango. ("identical" meaning that when the 
 Tango code is ported to D2, it will be identical to the Phobos2 
 version, except for module name differences).


 
 Please read it again. I'm not asking the question "where do we put it?"
 Rather, to agree that it WILL eventually go SOMEWHERE. If we agree on 
 that, there are immediate implications. Those modules have some 
 functions which differ in naming (mostly in case). That's a difference 
 we can fix right now without the politics.


I do agree it's a right direction to extract the common functionality 
and put it in a one place. But it's a question to the Phobos and Tango 
maintainers. After all, more time consuming efforts are needed.

Indeed , I don't think there's a person who don't want to see it happen.

Cheers
Piotrek
Feb 06 2009
parent reply Don <nospam nospam.com> writes:
Piotrek wrote:

 Don pisze:

 Don wrote:

 With the druntime project, we now have a run time which is shared 
 between Tango and Phobos. This is a huge step forward, but it's still 
 not much use without some common user code.

 The highest priorities which I see are, in order:
 (1) the C standard library
 tango.stdc = std.stdc
 (2) low-level compiler-related modules
 most of tango.core -- for the most part, this is already part of 
 druntime.
 (3) tango.math.Math + tango.math.IEEE  = std.math - tgamma().

 Can we get agreement on unification of these, at least?

 If we are able to reach agreement on this, I propose the next step 
 would be to ensure that the contents of these files be made 
 "identical" on Phobos2 and Tango. ("identical" meaning that when the 
 Tango code is ported to D2, it will be identical to the Phobos2 
 version, except for module name differences).


 Please read it again. I'm not asking the question "where do we put it?"
 Rather, to agree that it WILL eventually go SOMEWHERE. If we agree on 
 that, there are immediate implications. Those modules have some 
 functions which differ in naming (mostly in case). That's a difference 
 we can fix right now without the politics.


 
 I do agree it's a right direction to extract the common functionality 
 and put it in a one place. But it's a question to the Phobos and Tango 
 maintainers. After all, more time consuming efforts are needed.


No, it's a question to the community. I'm the primary maintainer of the 
math modules in both libraries. The efforts are straightforwards and not 
very time consuming. But I don't think I can break code just because I 
have a personal desire for unity.


 Indeed , I don't think there's a person who don't want to see it happen.


Are people OK with some of their code breaking for the sake of unity?
For the math stuff, that would mean name changes on minor functions such as:
isnormal() -> isNormal()

I need a mandate.
Feb 07 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Don:

 Are people OK with some of their code breaking for the sake of unity?
 For the math stuff, that would mean name changes on minor functions such as:
 isnormal() -> isNormal()


I follow the D standard, so I always use names like isNormal(), but they
require the extra shift pressure, and sometimes they are as readable as the
lowercase names. So often I'd like to see lowercase names, when possible (as in

everywhere, it makes the code a bit more visually noisy.

Bye,
bearophile
Feb 07 2009
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Don wrote:
...

 Are people OK with some of their code breaking for the sake of unity?
 For the math stuff, that would mean name changes on minor functions such 


as:

 isnormal() -> isNormal()
 
 I need a mandate.


Yes I think that's more than worth it. For D2 direction is to move towards 
compatibility and code breaking will happen anyway. Beyond mere runtime 
compatibility any unification that is uncontroversial is a no brainer imho.
Feb 07 2009
prev sibling next sibling parent Piotrek <starpit tlen.pl> writes:
Don wrote:

 
 Are people OK with some of their code breaking for the sake of unity?
 For the math stuff, that would mean name changes on minor functions such 
 as:
 isnormal() -> isNormal()
 
 I need a mandate.


My personal point of view (from what I've learned so far) is as follows:

Fortunately druntime and other Phobos/Tango merging actions are 
dedicated to D2.
D2 is on the development stage so there shouldn't be any complaint about 
breaking changes that are made for better functionality. There's so many 
good programmers in the community that it's a big pity not to combine 
their work as much as possible (sometimes division are needed when no 
agreement is possible)

Minutes spent for renaming functions or update argument list are not 
even compared with a better functionality increased faster thanks to 
unity - minutes spent vs months earned in total account. Note that 
braking changes for D1 Tango are on the rush before 1.0 version. Have 
you seen any complaint or riot.

IMHO you have the mandate as a maintainer - you are (as Walter, Andrei 
and Tango Team) to take pros and cons and make right decision. And time 
is now before D2 released (unless it's too late).

Cheers
Piotrek
Feb 07 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Don wrote:

 Piotrek wrote:

 Don pisze:

 Don wrote:

 With the druntime project, we now have a run time which is shared 
 between Tango and Phobos. This is a huge step forward, but it's 
 still not much use without some common user code.

 The highest priorities which I see are, in order:
 (1) the C standard library
 tango.stdc = std.stdc
 (2) low-level compiler-related modules
 most of tango.core -- for the most part, this is already part of 
 druntime.
 (3) tango.math.Math + tango.math.IEEE  = std.math - tgamma().

 Can we get agreement on unification of these, at least?

 If we are able to reach agreement on this, I propose the next step 
 would be to ensure that the contents of these files be made 
 "identical" on Phobos2 and Tango. ("identical" meaning that when the 
 Tango code is ported to D2, it will be identical to the Phobos2 
 version, except for module name differences).


 Please read it again. I'm not asking the question "where do we put it?"
 Rather, to agree that it WILL eventually go SOMEWHERE. If we agree on 
 that, there are immediate implications. Those modules have some 
 functions which differ in naming (mostly in case). That's a 
 difference we can fix right now without the politics.


 I do agree it's a right direction to extract the common functionality 
 and put it in a one place. But it's a question to the Phobos and Tango 
 maintainers. After all, more time consuming efforts are needed.


 
 No, it's a question to the community. I'm the primary maintainer of the 
 math modules in both libraries. The efforts are straightforwards and not 
 very time consuming. But I don't think I can break code just because I 
 have a personal desire for unity.
 

 Indeed , I don't think there's a person who don't want to see it happen.


 
 Are people OK with some of their code breaking for the sake of unity?
 For the math stuff, that would mean name changes on minor functions such 
 as:
 isnormal() -> isNormal()
 
 I need a mandate.


I hereby grant you that mandate. Feel free to mess with other names too, 
and let's exchange email when there's ambiguity.

The convention I'd like to use for templates is the following: if the 
template ultimately resolves in a type, e.g. BaseClassesTuple, start 
with uppercase. If it resolves in a compile-time constant or a function, 
e.g. hasAliasing, start with lowercase. By the way, what happened to 
std.traits and std.typecons? They are two of my faves and are growing as 
we speak.


Andrei
Feb 07 2009
next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Andrei Alexandrescu wrote:

 By the way, what happened to 
 std.traits and std.typecons? They are two of my faves and are growing as 
 we speak.
 
 Andrei


std.traits and tango.core.Traits have a number of superficial 
differences, such as ReturnType versus ReturnTypeOf, ParameterTypeTuple 
versus ParameterTupleOf, and so forth. This has been a source of 
annoyance for me in the past, until I decided to give up on it and just 
go with Tango. (I think the other part that decided it was Phobos's 
Variant type.)

tango.core.Traits has more than Phobos1's std.traits, but Phobos2 has 
most of that functionality. Is there any reason not to backport it?
Feb 07 2009
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
Andrei Alexandrescu wrote:

 Don wrote:

 Piotrek wrote:

 Don pisze:

 Don wrote:

 With the druntime project, we now have a run time which is shared 
 between Tango and Phobos. This is a huge step forward, but it's 
 still not much use without some common user code.

 The highest priorities which I see are, in order:
 (1) the C standard library
 tango.stdc = std.stdc
 (2) low-level compiler-related modules
 most of tango.core -- for the most part, this is already part of 
 druntime.
 (3) tango.math.Math + tango.math.IEEE  = std.math - tgamma().

 Can we get agreement on unification of these, at least?

 If we are able to reach agreement on this, I propose the next step 
 would be to ensure that the contents of these files be made 
 "identical" on Phobos2 and Tango. ("identical" meaning that when 
 the Tango code is ported to D2, it will be identical to the Phobos2 
 version, except for module name differences).


 Please read it again. I'm not asking the question "where do we put it?"
 Rather, to agree that it WILL eventually go SOMEWHERE. If we agree 
 on that, there are immediate implications. Those modules have some 
 functions which differ in naming (mostly in case). That's a 
 difference we can fix right now without the politics.


 I do agree it's a right direction to extract the common functionality 
 and put it in a one place. But it's a question to the Phobos and 
 Tango maintainers. After all, more time consuming efforts are needed.


 No, it's a question to the community. I'm the primary maintainer of 
 the math modules in both libraries. The efforts are straightforwards 
 and not very time consuming. But I don't think I can break code just 
 because I have a personal desire for unity.


 Indeed , I don't think there's a person who don't want to see it happen.


 Are people OK with some of their code breaking for the sake of unity?
 For the math stuff, that would mean name changes on minor functions 
 such as:
 isnormal() -> isNormal()

 I need a mandate.




I'm in agreement.


 The convention I'd like to use for templates is the following: if the 
 template ultimately resolves in a type, e.g. BaseClassesTuple, start 
 with uppercase. If it resolves in a compile-time constant or a function, 
 e.g. hasAliasing, start with lowercase.


This is the convention I use as well, and I think it's a good one.


Sean
Feb 07 2009
prev sibling next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Don (nospam nospam.com)'s article

 No, it's a question to the community. I'm the primary maintainer of the
 math modules in both libraries. The efforts are straightforwards and not
 very time consuming. But I don't think I can break code just because I
 have a personal desire for unity.

 Indeed , I don't think there's a person who don't want to see it happen.


 Are people OK with some of their code breaking for the sake of unity?
 For the math stuff, that would mean name changes on minor functions such as:
 isnormal() -> isNormal()
 I need a mandate.


Absolutely I am ok with code breaking for the sake of unity.  If I hear one more
word about backwards compatibility in the D2 branch, until D is a mature,
established language, I'm going to go crazy.  The whole point of D is that we
think C++, Java, etc. have stagnated and are willing to break compatibility with
legacy code to build a better language (and by extension, libraries).  The whole
point of D2 is that it's a bleeding edge alpha where stuff may break.  If my
code
breaks, especially in such trivial ways, in the short run so that we can have a
language and libraries that don't suck and aren't unnecessarily balkanized in
the
long run (unnecessarily meaning without having different design philosophies),
I'm
all for it.
Feb 07 2009
prev sibling next sibling parent Chad J <gamerchad __spam.is.bad__gmail.com> writes:
Don wrote:

 
 Are people OK with some of their code breaking for the sake of unity?


I am absolutely fine with this.  Please do make the D platform better!
Feb 07 2009
prev sibling next sibling parent Moritz Warning <moritzwarning web.de> writes:
On Sat, 07 Feb 2009 10:35:37 +0100, Don wrote:


 
 Are people OK with some of their code breaking for the sake of unity?
 For the math stuff, that would mean name changes on minor functions such
 as: isnormal() -> isNormal()
 
 I need a mandate.


You have my vote.
Feb 07 2009
prev sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
Don wrote:


 Are people OK with some of their code breaking for the sake of unity?
 For the math stuff, that would mean name changes on minor functions such  
 as:
 isnormal() -> isNormal()

 I need a mandate.


Aye, I say!

--
Simen
Feb 07 2009
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Don wrote:

 Please read it again. I'm not asking the question "where do we put it?"
 Rather, to agree that it WILL eventually go SOMEWHERE. If we agree on 
 that, there are immediate implications. Those modules have some 
 functions which differ in naming (mostly in case). That's a difference 
 we can fix right now without the politics.


Any chance of getting some aliases?
Feb 07 2009
parent Don <nospam nospam.com> writes:
Robert Fraser wrote:

 Don wrote:

 Please read it again. I'm not asking the question "where do we put it?"
 Rather, to agree that it WILL eventually go SOMEWHERE. If we agree on 
 that, there are immediate implications. Those modules have some 
 functions which differ in naming (mostly in case). That's a difference 
 we can fix right now without the politics.


 
 Any chance of getting some aliases?


If it's necessary. There's a few places where breakage is inevitable, 
though. And there's a few C functions with names which are IMHO 
unbelievably awful and deserve to die without mercy.
Why would you call the most useful conversion from float->integer 
function (better than cast(long)) "lrint()" ???
Feb 07 2009
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Don wrote:

 Don wrote:

 With the druntime project, we now have a run time which is shared 
 between Tango and Phobos. This is a huge step forward, but it's still 
 not much use without some common user code.

 The highest priorities which I see are, in order:
 (1) the C standard library
 tango.stdc = std.stdc
 (2) low-level compiler-related modules
 most of tango.core -- for the most part, this is already part of 
 druntime.
 (3) tango.math.Math + tango.math.IEEE  = std.math - tgamma().

 Can we get agreement on unification of these, at least?

 If we are able to reach agreement on this, I propose the next step 
 would be to ensure that the contents of these files be made 
 "identical" on Phobos2 and Tango. ("identical" meaning that when the 
 Tango code is ported to D2, it will be identical to the Phobos2 
 version, except for module name differences).


 
 Please read it again. I'm not asking the question "where do we put it?"
 Rather, to agree that it WILL eventually go SOMEWHERE. If we agree on 
 that, there are immediate implications. Those modules have some 
 functions which differ in naming (mostly in case). That's a difference 
 we can fix right now without the politics.


I support it, but I don't use these functions. A few changes in case 
wouldn't bother me in any case (except all upper, or small caps).
Feb 07 2009
parent "Joel C. Salomon" <joelcsalomon gmail.com> writes:
Christopher Wright wrote:

 I support it, but I don't use these functions. A few changes in case
 wouldn't bother me in any case (except all upper, or small caps).


ᴡʜy ᴀʀe ʏᴏᴜ ᴏᴘᴘosᴇᴅ ᴛo sᴍᴀʟʟ-ᴄᴀᴘs ɪɴ
ᴄᴏᴅᴇ?

—Joel Salomon
Feb 07 2009