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


 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


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 


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


libriraries.  The contintion will no doubt eventually lead to a  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.

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


 libriraries.  The contintion will no doubt eventually lead to a  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.


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


 libriraries.  The contintion will no doubt eventually lead to a  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.


 
 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


 libriraries.  The contintion will no doubt eventually lead to a  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.


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


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


 libriraries.  The contintion will no doubt eventually lead to a  
 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.


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


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


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