www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The great compromise of the D standard library

reply Ender KaShae <astrothayne gmail.com> writes:
I have great misgivings over the divide among the D community between standard
libriraries.  The contintion will no doubt eventually lead to a  schism reduce
the reusibility of D code.  I suggest the following compromise:

1.) Phobos and Tango are combined into a single Standard library, as Phobos
seems to be lower level, it would make sense for Tango to call Phobos functions
and for alias's to be made between equivilent entities that exist in both
libraries

2.) Programmers are incouraged to contribute to the new standard library

3.) Walter will remain the final say on what contributions are added to the
library

4.) The name for the standard library will be neutral between Digital Mars and
DSource

I believe this compromise will address most of the issues though it would have
to be agreed upon by both factions.  This has the additional advantage have
creating a library with both low level procedural and higher level
object-oriented parts.  This hybridization is one of the things that attracted
me most to D in the first place.

as an aside I believe there should be a more standardized way to suggest
changes to the D language 
Oct 17 2007
next sibling parent Nathan Reed <nathaniel.reed gmail.com> writes:
Ender KaShae wrote:
 I have great misgivings over the divide among the D community between standard
libriraries.  The contintion will no doubt eventually lead to a  schism reduce
the reusibility of D code.  I suggest the following compromise:
 
 1.) Phobos and Tango are combined into a single Standard library

This is taking place. It will be slow, but it will happen. Thanks, Nathan Reed
Oct 17 2007
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Ender KaShae wrote:
 I have great misgivings over the divide among the D community between standard
libriraries.  The contintion will no doubt eventually lead to a  schism reduce
the reusibility of D code.  I suggest the following compromise:
 
 1.) Phobos and Tango are combined into a single Standard library, as Phobos
seems to be lower level, it would make sense for Tango to call Phobos functions
and for alias's to be made between equivilent entities that exist in both
libraries

I'll leave the remaining points to others, but I believe this assessment is incorrect. One could argue that Tango scales higher than Phobos, but both are equivalent in terms of low-level coverage. The design is merely different. Sean
Oct 17 2007
next sibling parent Gregor Richards <Richards codu.org> writes:
Sean Kelly wrote:
 Ender KaShae wrote:
 I have great misgivings over the divide among the D community between 
 standard libriraries.  The contintion will no doubt eventually lead to 
 a  schism reduce the reusibility of D code.  I suggest the following 
 compromise:

 1.) Phobos and Tango are combined into a single Standard library, as 
 Phobos seems to be lower level, it would make sense for Tango to call 
 Phobos functions and for alias's to be made between equivilent 
 entities that exist in both libraries

I'll leave the remaining points to others, but I believe this assessment is incorrect. One could argue that Tango scales higher than Phobos, but both are equivalent in terms of low-level coverage. The design is merely different. Sean

Also, although Sean is clearly too humble to say this, Tango's low-level core is superior by leaps and bounds. - Gregor Richards
Oct 17 2007
prev sibling next sibling parent 0ffh <spam frankhirsch.net> writes:
Sean Kelly wrote:
 Ender KaShae wrote:
 [...]
 1.) Phobos and Tango are combined into a single Standard library, as 
 Phobos seems to be lower level, it would make sense for Tango to call 
 Phobos functions and for alias's to be made between equivilent 
 entities that exist in both libraries

I'll leave the remaining points to others, but I believe this assessment is incorrect. [...]

So do I. Some people seem to associate the free functions style with "low level" and oo style with "high level". It's a mistake I've seen repeated in this ng over and over again.... Regards, Frank
Oct 18 2007
prev sibling parent reply Mikola Lysenko <mclysenk mtu.edu> writes:
Sean Kelly Wrote:

 Ender KaShae wrote:
 I have great misgivings over the divide among the D community between standard
libriraries.  The contintion will no doubt eventually lead to a  schism reduce
the reusibility of D code.  I suggest the following compromise:
 
 1.) Phobos and Tango are combined into a single Standard library, as Phobos
seems to be lower level, it would make sense for Tango to call Phobos functions
and for alias's to be made between equivilent entities that exist in both
libraries

I'll leave the remaining points to others, but I believe this assessment is incorrect. One could argue that Tango scales higher than Phobos, but both are equivalent in terms of low-level coverage. The design is merely different. Sean

I'd even go so far as to say that at the very lowest level, Tango is the decisive winner. Any project involving either threads or networking should stay away from Phobos. There are still all kinds of outstanding bugs from *years* ago, including crowd favorites such as issue 318: http://d.puremagic.com/issues/show_bug.cgi?id=318 As if the bugs weren't enough, the implementation of Phobos' Threads is also much slower. Simple things like Thread.getThis are O(n) in Phobos and O(1) in Tango. It is also missing features like thread local storage and Fibers. Ultimately switching Tango to Phobos' core would be a big step backwards. -Mik
Oct 18 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Mikola Lysenko wrote:
 Sean Kelly Wrote:
 
 Ender KaShae wrote:
 I have great misgivings over the divide among the D community between standard
libriraries.  The contintion will no doubt eventually lead to a  schism reduce
the reusibility of D code.  I suggest the following compromise:

 1.) Phobos and Tango are combined into a single Standard library, as Phobos
seems to be lower level, it would make sense for Tango to call Phobos functions
and for alias's to be made between equivilent entities that exist in both
libraries

is incorrect. One could argue that Tango scales higher than Phobos, but both are equivalent in terms of low-level coverage. The design is merely different. Sean

I'd even go so far as to say that at the very lowest level, Tango is the decisive winner. Any project involving either threads or networking should stay away from Phobos. There are still all kinds of outstanding bugs from *years* ago, including crowd favorites such as issue 318: http://d.puremagic.com/issues/show_bug.cgi?id=318

Technically speaking, 2006 is only one year ago, not "years". :-) But still it's a long time. --bb
Oct 18 2007
prev sibling next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Ender KaShae wrote:

 I have great misgivings over the divide among the D community between
 standard libriraries.  The contintion will no doubt eventually lead to a 
 schism reduce the reusibility of D code.  I suggest the following
 compromise:
 
 1.) Phobos and Tango are combined into a single Standard library, as
 Phobos seems to be lower level, it would make sense for Tango to call
 Phobos functions and for alias's to be made between equivilent entities
 that exist in both libraries

As have been said before, this won't happen. This will degrade Tango's performance. It does not make sense at all.
 3.) Walter will remain the final say on what contributions are added to
 the library

This is how Phobos has worked, and is a main reasons for criticism against how Phobos has been controlled. This is a proven dead end.
 I believe this compromise will address most of the issues though it would
 have to be agreed upon by both factions.  This has the additional
 advantage have creating a library with both low level procedural and
 higher level object-oriented parts.  This hybridization is one of the
 things that attracted me most to D in the first place.

Note that the user API (std.* and tango.*) isn't really an issue at hand here, at least not now, the runtime (GC, Thread, Object) is.
 as an aside I believe there should be a more standardized way to suggest
 changes to the D language

FWIW, I agree with you on this point :) -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Oct 18 2007
prev sibling next sibling parent Alexander Panek <alexander.panek brainsware.org> writes:
On Wed, 17 Oct 2007 18:05:17 -0400
Ender KaShae <astrothayne gmail.com> wrote:
 2.) Programmers are incouraged to contribute to the new standard
 library

Tango.Scrapple? Anyone?
 3.) Walter will remain the final say on what contributions are added
 to the library

I don't think Walter has the /time/ to do so, and given the fact that he wouldn't be the only one, or not even the main developer, working on given standard runtime library, this seems suboptimal. I do think, however, that Tango's developers are doing a pretty good job in that regard, anyways.
 4.) The name for the standard library will be neutral between Digital
 Mars and DSource

What do you mean with neutral? Also in what way is DSource directly involved with this?
 I believe this compromise will address most of the issues though it
 would have to be agreed upon by both factions.  This has the
 additional advantage have creating a library with both low level
 procedural and higher level object-oriented parts.  This
 hybridization is one of the things that attracted me most to D in the
 first place.

I don't want to repeat myself, but: Tango does a pretty good job in that regard, too, as it uses classes (which require object allocation, mind you) only when it is (by design, not absolutely - we're not talking C, after all) necessary, and provides freestanding functions where they're sufficiant.
 as an aside I believe there should be a more standardized way to
 suggest changes to the D language 

In what way more standardized? -- Alexander Panek <alexander.panek brainsware.org>
Oct 18 2007
prev sibling next sibling parent reply "Kris" <foo bar.com> writes:
"Ender KaShae" <astrothayne gmail.com> wrote in message
I have great misgivings over the divide among the D community between 
standard libriraries.  The contintion will no doubt eventually lead to a 
schism reduce the reusibility of D code.

Choice is not such a bad thing at times. If Tango did not exist, things would be arguably a lot worse for D. After all, it was written by people who feel a desire to inject D into the commercial development space, where phobos could not even be considered as a realistic option. To be clear, Tango is targeted at the commercial space. Also, I think you'll find that all the major D libraries are operational and maintained upon Tango. There's likely to be good reason for that.
 1.) Phobos and Tango are combined into a single Standard library, as 
 Phobos seems to be lower level, it would make sense for Tango to call 
 Phobos functions and for alias's to be made between equivilent entities 
 that exist in both libraries

You'll forgive me, but this is apparently something said without even a vague inkling of why Tango exists or what the distinctions might be. It's so grossly simplified that it's hard to even begin an explanation :) I will note that Tango is a de-coupled design, and thus can be happily deployed in a variety of configurations. The lower level is known to be considerably more capable and robust than the phobos equivalent, so Tango is basically a better library right at the very basic core.
 2.) Programmers are incouraged to contribute to the new standard library

That is exactly what Tango is all about. And it shows in the breadth and depth of the library. There are significant contributions from people with exceptional talent, and that's what gives Tango much of its strength.
 3.) Walter will remain the final say on what contributions are added to 
 the library

Walter is a supreme compiler-writer but, and I'm sure he won't mind me saying so, he is not a supreme library designer. In fact, the requirements for what makes a good language designer are arguably diametrically opposed to what makes for a good library designer. I suspect you give the Tango folks far too little credit ... or perhaps they're just a bunch of rank amateurs after all :)
 4.) The name for the standard library will be neutral between Digital Mars 
 and DSource

 I believe this compromise will address most of the issues though it would 
 have to be agreed upon by both factions.

If only it were that easy! Unfortunately what you describe is a compromise with the worst of everything and little realistic value. Take that with a pinch of salt if you prefer, but some of us have been around long enough to understand the tradeoffs as well as anyone. Probably better than most.
 This has the additional advantage have creating a library with both low 
 level procedural and higher level object-oriented parts.  This 
 hybridization is one of the things that attracted me most to D in the 
 first place.

An oft-stated point. A more procedural layer is something that was promised for Tango during the D conference, so it is being worked on. We've been overly conservative about the library in general, but now that the tyres have been kicked sufficiently you'll see some neat things happening soon enough. BTW: this opinion that Tango's all about OO is just wildly incorrect ... there's perhaps more vanilla functions and IFTI templates than there are classes in Tango (it's a modern library of considerable depth) and, conversely, phobos has a significant percentage of classes also. What appears to propagate this false notion is that some rather specific library functionality happens to be OO in Tango and not in phobos. It may well be true that Tango is /more/ OO than phobos, but then it is also a substantially broader and deeper library. Some types of library functionality are simply better suited to OO, which is why phobos often uses that model also. There's a whole lot of misconception in this arena, some of which was spawned early on when Tango was still quite young and even more conservative. You talk about merging functionality. In order to get a rather vague picture of functionality, I suggest you count the number of modules in std.* and compare that against the number in tango.* :: the tango example called filescan.d tells me there's around 300 D modules in Tango, with around 75 in phobos. Because of the de-coupled and layered nature of Tango, it is actually easier to get it running on a new platform, despite the breadth. There's far less bottom-to-top architectural inter-connectivity to trip you up, since there's been a lot of effort made to explicitly avoid that. Actually merging Tango into phobos would cause the latter to basically disappear as background noise ... they are that different in respective capability. You might as well compare a 1982 C library, with that of C# In the past, we've made a deliberate effort to avoid comparing phobos against Tango, but in the last month there's been so much misinformation that we've started to take the gloves off a little. Yes, some people prefer the 'style' of phobos. Good! Variety is the spice of life. Having said that, Tango will carefully add in some of that 'style' that some people prefer. I hope this gives you, Ender, some kind of insight into the realities of Tango :p
Oct 18 2007
parent reply Ender KaShae <astrothayne gmail.com> writes:
Yes, I obviosly didn't understand everything about tango, and my compromise was
a  little rash, however in my first point I believe I was misinterpreted,
though I can see why.  When I said Tango should call phobos functions I was
assuming that phobos would first be fixed to be just as efficient as Tango.  AS
it is these are the issues i have with tango:

1.) it is not compatible with phobos, i see this as the biggest problem, not
because phobos is such a great library but because it is difficult if not
impossible to import libraries that use phobos alongside libraries that use
tango
2.) it does not ship with DMD
3.) it is more difficult to navigate than phobos

my revised solution is to make tango completly phobos compatible (without
changing the runtime, maybe having phobos just call the equivilent in tango)
and make tango the ONLY standard library
Oct 19 2007
next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Ender KaShae wrote:
 3.) it [Tango] is more difficult to navigate than phobos

Would it help if the API reference were hierarchical rather than just enumerating all the packages? That is: tango | core | | Array | | Atomic ... | io | | Buffer ...
Oct 19 2007
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Christopher Wright wrote:
 Ender KaShae wrote:
 3.) it [Tango] is more difficult to navigate than phobos

Would it help if the API reference were hierarchical rather than just enumerating all the packages? That is: tango | core | | Array | | Atomic ... | io | | Buffer ...

The ideal system IMO would be to have a javadoc like system with integrated comments system like php has. also currently if i press on any symbol i get an error page. I'd like to be able to alternate between an explanation page with usage examples and comments, and the source listing which should rely on links to symbols. doesn't doxygen already does it all? well, besides the integrated comment system...
Oct 19 2007
parent reply Thayne McCombs <astrothayne gmail.com> writes:
Yigal Chripun Wrote:

 Christopher Wright wrote:
 Ender KaShae wrote:
 3.) it [Tango] is more difficult to navigate than phobos

Would it help if the API reference were hierarchical rather than just enumerating all the packages? That is: tango | core | | Array | | Atomic ... | io | | Buffer ...

The ideal system IMO would be to have a javadoc like system with integrated comments system like php has. also currently if i press on any symbol i get an error page. I'd like to be able to alternate between an explanation page with usage examples and comments, and the source listing which should rely on links to symbols. doesn't doxygen already does it all? well, besides the integrated comment system...

more than anything, the incomplete documentation makes it difficult to navigate through tango. Couple this to some names that are not self-intuitive and it becomes potentially very confusing. What if that cryptically named class that is missing documentations is what I need?
Oct 20 2007
parent "Kris" <foo bar.com> writes:
"Thayne McCombs" <astrothayne gmail.com> wrote in message news:ffdoc9

 more than anything, the incomplete documentation makes it difficult to 
 navigate through tango.

If that is the case, would you consider helping to fix it?
Oct 20 2007
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Ender KaShae wrote:

 Yes, I obviosly didn't understand everything about tango, and my
 compromise was a  little rash, however in my first point I believe I was
 misinterpreted, though I can see why.  When I said Tango should call
 phobos functions I was assuming that phobos would first be fixed to be
 just as efficient as Tango.  AS it is these are the issues i have with
 tango:
 
  2.) it does not ship with DMD

This is ambigious and thus half wrong :) DMD don't ship with Tango, but Tango ships with DMD. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Oct 20 2007
parent reply Thayne McCombs <astrothayne gmail.com> writes:
Lars Ivar Igesund Wrote:

 Ender KaShae wrote:
 
 Yes, I obviosly didn't understand everything about tango, and my
 compromise was a  little rash, however in my first point I believe I was
 misinterpreted, though I can see why.  When I said Tango should call
 phobos functions I was assuming that phobos would first be fixed to be
 just as efficient as Tango.  AS it is these are the issues i have with
 tango:
 
  2.) it does not ship with DMD

This is ambigious and thus half wrong :) DMD don't ship with Tango, but Tango ships with DMD.

the issue is that there is no garantee that you get the latest version of dmd (in fact when i when just downloaded tango it came with v. 1.021)
Oct 20 2007
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Thayne McCombs wrote:

 Lars Ivar Igesund Wrote:
 
 Ender KaShae wrote:
 
 Yes, I obviosly didn't understand everything about tango, and my
 compromise was a  little rash, however in my first point I believe I
 was
 misinterpreted, though I can see why.  When I said Tango should call
 phobos functions I was assuming that phobos would first be fixed to be
 just as efficient as Tango.  AS it is these are the issues i have with
 tango:
 
  2.) it does not ship with DMD

This is ambigious and thus half wrong :) DMD don't ship with Tango, but Tango ships with DMD.

the issue is that there is no garantee that you get the latest version of dmd (in fact when i when just downloaded tango it came with v. 1.021)

Potentially a problem, yes, but you also get a version that has been tested with Tango. DMD releases breaking Tango have happened many times. Feel free to request status for newer versions if we seem un-neededly late. Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Oct 20 2007
prev sibling parent reply Darryl B <darrylbleau gmail.com> writes:
== Quote from Ender KaShae (astrothayne gmail.com)'s article
 I have great misgivings over the divide among the D community between standard

reusibility of D code. I absolutely agree with this point. One of the first eyebrow-raising experiences for me, moving to D, was learning of this 'alternate' standard library. The 'D' standard library should be 'the' D standard library, shouldn't it? You may as well be writing in a different language, going from one lib to the other. You really have to specify which 'flavor' of D you use when speaking to others, and a Tango dev may not even want to look at a problem someone has if they were using Phobos. The separation of the 'D-Tango' and 'D-Phobos' factions is detrimental to the D language as a whole, IMO. That being said, I think it unlikely that 'merging' will even happen (which I think would mostly end up more as 'Tango shoving Phobos out the window' than 'Merging', anyway), for the same reasons we have things like different window managers (think KDE/Gnome). The best to hope for, I think, is that one lib becomes so actively developed and used that the other lib just scurries away and finds a nice comfortable place to die, leaving all of it's developers free to contribute to the surviving lib.
Oct 18 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Darryl B wrote:
 == Quote from Ender KaShae (astrothayne gmail.com)'s article
 I have great misgivings over the divide among the D community between standard

reusibility of D code. I absolutely agree with this point. One of the first eyebrow-raising experiences for me, moving to D, was learning of this 'alternate' standard library. The 'D' standard library should be 'the' D standard library, shouldn't it? You may as well be writing in a different language, going from one lib to the other. You really have to specify which 'flavor' of D you use when speaking to others, and a Tango dev may not even want to look at a problem someone has if they were using Phobos. The separation of the 'D-Tango' and 'D-Phobos' factions is detrimental to the D language as a whole, IMO.

There's also D2.0 which is a completely different, incompatible version of D. So really there are *three* different incompatible versions of D to choose from right now (yes you can get some source code to compile with both D1 and D2, just like you can get some code to compile with either Tango or Phobos). I was all for adding of const to D, but my vision was for it to get added relatively quickly and become the one-and-only D. Add it quickly, get everyone to fix their code, and then forget there ever was a D without const. Leave it in the dust. Just like we forgot about D with regular expression literals, or D with the === operator. But instead we got a D-without-const codified as a permanent, unchanging standard and D-with-const as a new, incompatible, competing standard. Taking a step back it just seems really silly for a niche language like D to have so many factions. So here's a little proposal to maybe help mend the D1/D2 schism a bit: add -v2 compatiblity switch to D1 that would cause it to just ignore D2's const and invariant declarations. That would make writing code that works on both a lot easier. After porting a bit of D2's std.* to D1, it seems that the main issues are just const(foo)[] and invariant(foo)[] constructs here and there. The fix is almost always just to remove them. So if the D1 compiler could be made to ignore those then that would remove most of the hassle of making code compatible between D1 and D2. --bb
Oct 18 2007
parent reply Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Bill Baxter Wrote:

 Darryl B wrote:
 == Quote from Ender KaShae (astrothayne gmail.com)'s article
 I have great misgivings over the divide among the D community between standard

reusibility of D code. I absolutely agree with this point. One of the first eyebrow-raising experiences for me, moving to D, was learning of this 'alternate' standard library. The 'D' standard library should be 'the' D standard library, shouldn't it? You may as well be writing in a different language, going from one lib to the other. You really have to specify which 'flavor' of D you use when speaking to others, and a Tango dev may not even want to look at a problem someone has if they were using Phobos. The separation of the 'D-Tango' and 'D-Phobos' factions is detrimental to the D language as a whole, IMO.

There's also D2.0 which is a completely different, incompatible version of D. So really there are *three* different incompatible versions of D to choose from right now (yes you can get some source code to compile with both D1 and D2, just like you can get some code to compile with either Tango or Phobos). I was all for adding of const to D, but my vision was for it to get added relatively quickly and become the one-and-only D. Add it quickly, get everyone to fix their code, and then forget there ever was a D without const. Leave it in the dust. Just like we forgot about D with regular expression literals, or D with the === operator. But instead we got a D-without-const codified as a permanent, unchanging standard and D-with-const as a new, incompatible, competing standard. Taking a step back it just seems really silly for a niche language like D to have so many factions. So here's a little proposal to maybe help mend the D1/D2 schism a bit: add -v2 compatiblity switch to D1 that would cause it to just ignore D2's const and invariant declarations. That would make writing code that works on both a lot easier. After porting a bit of D2's std.* to D1, it seems that the main issues are just const(foo)[] and invariant(foo)[] constructs here and there. The fix is almost always just to remove them. So if the D1 compiler could be made to ignore those then that would remove most of the hassle of making code compatible between D1 and D2. --bb

Is this really worth the hassle? If you check Walter's recent postings sorting out const is on the list for the next release. He know's it sucks, he started a thread on it remember. I don't think we have long to wait for the next try. He could get it wrong again but given all the feedback and some time to think maybe he's got it right this time (or at least right enough). Bruce.
Oct 19 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Bruce Adams wrote:
 Bill Baxter Wrote:
 
 Darryl B wrote:
 == Quote from Ender KaShae (astrothayne gmail.com)'s article
 I have great misgivings over the divide among the D community between standard

reusibility of D code. I absolutely agree with this point. One of the first eyebrow-raising experiences for me, moving to D, was learning of this 'alternate' standard library. The 'D' standard library should be 'the' D standard library, shouldn't it? You may as well be writing in a different language, going from one lib to the other. You really have to specify which 'flavor' of D you use when speaking to others, and a Tango dev may not even want to look at a problem someone has if they were using Phobos. The separation of the 'D-Tango' and 'D-Phobos' factions is detrimental to the D language as a whole, IMO.

of D. So really there are *three* different incompatible versions of D to choose from right now (yes you can get some source code to compile with both D1 and D2, just like you can get some code to compile with either Tango or Phobos). I was all for adding of const to D, but my vision was for it to get added relatively quickly and become the one-and-only D. Add it quickly, get everyone to fix their code, and then forget there ever was a D without const. Leave it in the dust. Just like we forgot about D with regular expression literals, or D with the === operator. But instead we got a D-without-const codified as a permanent, unchanging standard and D-with-const as a new, incompatible, competing standard. Taking a step back it just seems really silly for a niche language like D to have so many factions. So here's a little proposal to maybe help mend the D1/D2 schism a bit: add -v2 compatiblity switch to D1 that would cause it to just ignore D2's const and invariant declarations. That would make writing code that works on both a lot easier. After porting a bit of D2's std.* to D1, it seems that the main issues are just const(foo)[] and invariant(foo)[] constructs here and there. The fix is almost always just to remove them. So if the D1 compiler could be made to ignore those then that would remove most of the hassle of making code compatible between D1 and D2. --bb

Is this really worth the hassle? If you check Walter's recent postings sorting out const is on the list for the next release. He know's it sucks, he started a thread on it remember. I don't think we have long to wait for the next try. He could get it wrong again but given all the feedback and some time to think maybe he's got it right this time (or at least right enough).

D1.0 is still intended as a long-term support, stable version of D. So D1.0 is not going away for a while even if const turns into everybody's favorite feature of D2.0. And even if the new const design has everybody doing backflips of joy, code written using it it will still be incompatible with D1.0, and making it compatible will still be a pain since D lacks the equivalent of something like #define invariant /*nothing*/ --bb
Oct 19 2007
next sibling parent Reiner Pope <some address.com> writes:
Bill Baxter wrote:
 Bruce Adams wrote:
 Bill Baxter Wrote:

 Darryl B wrote:
 == Quote from Ender KaShae (astrothayne gmail.com)'s article
 I have great misgivings over the divide among the D community 
 between standard

schism reduce the reusibility of D code. I absolutely agree with this point. One of the first eyebrow-raising experiences for me, moving to D, was learning of this 'alternate' standard library. The 'D' standard library should be 'the' D standard library, shouldn't it? You may as well be writing in a different language, going from one lib to the other. You really have to specify which 'flavor' of D you use when speaking to others, and a Tango dev may not even want to look at a problem someone has if they were using Phobos. The separation of the 'D-Tango' and 'D-Phobos' factions is detrimental to the D language as a whole, IMO.

version of D. So really there are *three* different incompatible versions of D to choose from right now (yes you can get some source code to compile with both D1 and D2, just like you can get some code to compile with either Tango or Phobos). I was all for adding of const to D, but my vision was for it to get added relatively quickly and become the one-and-only D. Add it quickly, get everyone to fix their code, and then forget there ever was a D without const. Leave it in the dust. Just like we forgot about D with regular expression literals, or D with the === operator. But instead we got a D-without-const codified as a permanent, unchanging standard and D-with-const as a new, incompatible, competing standard. Taking a step back it just seems really silly for a niche language like D to have so many factions. So here's a little proposal to maybe help mend the D1/D2 schism a bit: add -v2 compatiblity switch to D1 that would cause it to just ignore D2's const and invariant declarations. That would make writing code that works on both a lot easier. After porting a bit of D2's std.* to D1, it seems that the main issues are just const(foo)[] and invariant(foo)[] constructs here and there. The fix is almost always just to remove them. So if the D1 compiler could be made to ignore those then that would remove most of the hassle of making code compatible between D1 and D2. --bb

Is this really worth the hassle? If you check Walter's recent postings sorting out const is on the list for the next release. He know's it sucks, he started a thread on it remember. I don't think we have long to wait for the next try. He could get it wrong again but given all the feedback and some time to think maybe he's got it right this time (or at least right enough).

D1.0 is still intended as a long-term support, stable version of D. So D1.0 is not going away for a while even if const turns into everybody's favorite feature of D2.0. And even if the new const design has everybody doing backflips of joy, code written using it it will still be incompatible with D1.0, and making it compatible will still be a pain since D lacks the equivalent of something like #define invariant /*nothing*/ --bb

For what it's worth, something like this should probably work template Const(T) { version (D1) mixin("alias const(T) Const;"); else mixin("alias T Const;"); } -- Reiner
Oct 19 2007
prev sibling parent reply Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Bill Baxter Wrote:

 Bruce Adams wrote:
 
 Is this really worth the hassle? If you check Walter's recent postings sorting
out const is on the list for the next release.  He know's it sucks, he started
a thread on it remember. I don't think we have long to wait for the next try.
He could get it wrong again but given all the feedback and some time to think
maybe he's got it right this time (or at least right enough).

D1.0 is still intended as a long-term support, stable version of D. So D1.0 is not going away for a while even if const turns into everybody's favorite feature of D2.0. And even if the new const design has everybody doing backflips of joy, code written using it it will still be incompatible with D1.0, and making it compatible will still be a pain since D lacks the equivalent of something like #define invariant /*nothing*/ --bb

That doesn't make sense to me. Surely you want your old code to work with D2.0 but I see much less need to have your shiny new D2.0 code work with D1.0. That kind of like using the C subset of C++ albeit far less extreme. Bruce.
Oct 20 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Bruce Adams wrote:
 Bill Baxter Wrote:
 
 Bruce Adams wrote:
 Is this really worth the hassle? If you check Walter's recent postings sorting
out const is on the list for the next release.  He know's it sucks, he started
a thread on it remember. I don't think we have long to wait for the next try.
He could get it wrong again but given all the feedback and some time to think
maybe he's got it right this time (or at least right enough).

D1.0 is not going away for a while even if const turns into everybody's favorite feature of D2.0. And even if the new const design has everybody doing backflips of joy, code written using it it will still be incompatible with D1.0, and making it compatible will still be a pain since D lacks the equivalent of something like #define invariant /*nothing*/ --bb

That doesn't make sense to me. Surely you want your old code to work with D2.0 but I see much less need to have your shiny new D2.0 code work with D1.0. That kind of like using the C subset of C++ albeit far less extreme.

It would be a transitional measure. If people have to maintain two different versions of their libraries they will be less likely to move to 2.0, which slows the adoption of 2.0. People starting out afresh will be more likely to just stick with 2.0. But I started thinking a separate source code translator might be a better approach than adding unnecessary no-op constructs to D1.x. So write your code in 2.0, and use a translator to generate your D1.x sources off of that. The translator would only handle those kinds of low-level differences that are difficult to work around with version{} blocks. Like invariant(int)[] --> int[] and .idup --> dup. --bb
Oct 20 2007