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