www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: Any chance to call Tango as Extended Standard Library

reply IUnknown <a b.com> writes:
Whoa. Toe is really silly. I really don't think its a good name. 

begin/ end OR head/tail OR first / last 
next / prev or advance/ retreat like someone suggested. 

Regarding Phobos + Tango, the minimum I expect is things like containers,
algorithm and common math stuff to be in one core module. And these containers
should be used in both standard and any other libraries. Things like I/O can
have different interfaces to use based on the requirement. 

People have similar problems with OpenGL. No one single location for all
documentation (until recently). Multiple competing ways to do things for
different hardware vendors. Multiple core OpenGL methods to achieve the same
thing. And we have lots of people unable to find which one to use for the best
performance. Direct3D on the other hand has been becoming more streamlined and
centralized. 

How about asking your peers who have successful languages how good an idea this
is? I'm interested to know if only us mortals are not getting it or do people
like Steve Yegge, Steve McConnell, Andy Hunt, Dave Thomas also think its not a
problem to start of a language like this.
 
Just to be clear, I have the utmost respect for each of your skills and
expertise. But I think you guys really underestimate and do not like to focus
on things like presentation and easy communication which are very essential for
spreading software. Your technical goals for D are just great but then so
should the way you deliver it. (I also appreciate that you are giving this away
for free, so I'm not really demanding anything!) 

For peers at my level (4 years experience) I see a lot of uneasiness in trying
out something like D mostly due to reasons like this. 


Andrei Alexandrescu Wrote:

 Michel Fortin wrote:
 On 2009-01-18 10:21:55 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 
 It's been there for a while now (since 25 Nov 2008).

 http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement

.next move the left edge of the range right one .retreat move the right edge of the range left one Each time I see this I get annoyed by the dissimilarity of the terms. "advance" and "retreat" would be much better words. Even if "advance" is three more characters, it carries much better the meaning of what is happening; "next" isn't even a verb.

I understand. Next was rather consecrated so we used that one. "Toe" comes from the "head to toe" phrase; "tail" would have been nice but its meaning in all other languages is "everything but the head". At the highest level, any nomenclature cannot please everybody. Andrei

Jan 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
IUnknown wrote:
 Regarding Phobos + Tango, the minimum I expect is things like
 containers, algorithm and common math stuff to be in one core module.

This is already bound to be an issue because there is disagreement on how e.g. containers should look like (Java-style vs. STL-style). Which should be chosen? This naturally influences how algorithms are defined. Andrei
Jan 18 2009
next sibling parent reply IUnknown <a b.com> writes:
Agree. Which is why I said the problems you are facing seem to be
non-technical. I'm suggesting that the D library developers should pick one and
axe the other. *I* think what more important is to have one single set of
containers in a single style rather than have two separate ones. There is going
to be complaining for sure from the current developers, but in my opinion, the
target of having a single standard library (with core and advanced modules to
suit system/ app programming) is more important than having to make a difficult
choice. 

In other languages/ developer communities, the developers would present the two
alternatives with all the pros and cons on a web page (not email) and the
powers that be should vote on it, make the decision and move on with it. 

You already have this "divide" in C++ on how lots of people won't contribute to
a project unless it employs boost and on the other end you have people who have
not even heard of it or thing its too heavy for the project. The problem is
different here, but it might end up fragmenting the small community. 

D attempts to solve a lot of problems and I think it does it pretty well. There
might be a chance some mistakes creep in -- the "wrong" style might be picked.
It won't be a bigger problem than having two separate libraries IMHO. 

This is why I request you to consult other independent people and see what
their take on it is. From a library developer's perspective you would
invariably pit the decision against the difficulty in doing it. Hence my
suggestion to find out what users would really need and then try to implement
it. 

Andrei Alexandrescu Wrote:

 IUnknown wrote:
 Regarding Phobos + Tango, the minimum I expect is things like
 containers, algorithm and common math stuff to be in one core module.

This is already bound to be an issue because there is disagreement on how e.g. containers should look like (Java-style vs. STL-style). Which should be chosen? This naturally influences how algorithms are defined. Andrei

Jan 18 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
IUnknown wrote:
 This is why I request you to consult other independent people and see
 what their take on it is. From a library developer's perspective you
 would invariably pit the decision against the difficulty in doing it.
 Hence my suggestion to find out what users would really need and then
 try to implement it.

This I completely disagree with. 360 degrees :o). Good stuff comes from good vision, not from doing what people think they want (see PHP, American cars, and taking dating advice from female friends). I won't continue this because it will go the way philosophical debates usually go => a long exchange of long messages leading to nowhere in particular. Andrei
Jan 18 2009
next sibling parent reply IUnknown <a b.com> writes:
Andrei Alexandrescu Wrote:
 This I completely disagree with. 360 degrees :o). 

You mean 180? :D
Jan 18 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
IUnknown wrote:
 Andrei Alexandrescu Wrote:
 This I completely disagree with. 360 degrees :o). 

You mean 180? :D

The smiley should have given the joke away. Andrei
Jan 18 2009
prev sibling next sibling parent reply John Reimer <terminal.node gmail.com> writes:
Hello Andrei,

 IUnknown wrote:
 
 This is why I request you to consult other independent people and see
 what their take on it is. From a library developer's perspective you
 would invariably pit the decision against the difficulty in doing it.
 Hence my suggestion to find out what users would really need and then
 try to implement it.
 

from good vision, not from doing what people think they want (see PHP, American cars, and taking dating advice from female friends). I won't continue this because it will go the way philosophical debates usually go => a long exchange of long messages leading to nowhere in particular. Andrei

Oversimplification. Good stuff does not always come from good vision if it is poorly managed. IUnknown had a fair point that you had the option of taking or leaving. The suggestion was to look for advice for a problem to which you admitted having no solution. Obviously, you needn't take the advice. But reinterpreting his statement to a form that is absurd is not fair. You could have just as easily interpreted him as saying, "look over some historical examples and see if there are similar solutions to this problem from another's perspective". The philosophical debate is completely optional. On the other hand, a practical one is always available. :-D -JJR
Jan 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
John Reimer wrote:
 Hello Andrei,
 
 IUnknown wrote:

 This is why I request you to consult other independent people and see
 what their take on it is. From a library developer's perspective you
 would invariably pit the decision against the difficulty in doing it.
 Hence my suggestion to find out what users would really need and then
 try to implement it.

from good vision, not from doing what people think they want (see PHP, American cars, and taking dating advice from female friends). I won't continue this because it will go the way philosophical debates usually go => a long exchange of long messages leading to nowhere in particular. Andrei

Oversimplification. Good stuff does not always come from good vision if it is poorly managed.

Agreed. I'll also note I didn't claim "always".
 IUnknown had a fair point that you had the option of taking or leaving.  
 The suggestion was to look for advice for a problem to which you 
 admitted having no solution.
 
 
 Obviously, you needn't take the advice.  But reinterpreting his 
 statement to a form that is absurd is not fair.  You could have just as 
 easily interpreted him as saying, "look over some historical examples 
 and see if there are similar solutions to this problem from another's 
 perspective".

Oh, I didn't mean to demean what he said in any way. But taking his advice at this point in time is incompatible with my view, for the lack of a better word. Most of the issue is that for the most part said "view" is not palpable: it's the ranges I haven't implemented yet, the I/O I haven't designed yet, the containers I haven't implemented yet, and the threading library we haven't designed yet. At the same time, Tango as defined today itself does not take advantage of D2. So I'd find it odd to ask people at this point whether they'd choose between a library that essentially doesn't exist yet, and one that might improve by going through one more iteration. It's just too early for D2. Andrei
Jan 18 2009
parent John Reimer <terminal.node gmail.com> writes:
Hello Andrei,

 John Reimer wrote:
 
 Hello Andrei,
 
 IUnknown wrote:
 
 This is why I request you to consult other independent people and
 see what their take on it is. From a library developer's
 perspective you would invariably pit the decision against the
 difficulty in doing it. Hence my suggestion to find out what users
 would really need and then try to implement it.
 

from good vision, not from doing what people think they want (see PHP, American cars, and taking dating advice from female friends). I won't continue this because it will go the way philosophical debates usually go => a long exchange of long messages leading to nowhere in particular. Andrei

if it is poorly managed.


:-)
 IUnknown had a fair point that you had the option of taking or
 leaving.  The suggestion was to look for advice for a problem to
 which you admitted having no solution.
 
 Obviously, you needn't take the advice.  But reinterpreting his
 statement to a form that is absurd is not fair.  You could have just
 as easily interpreted him as saying, "look over some historical
 examples and see if there are similar solutions to this problem from
 another's perspective".
 

advice at this point in time is incompatible with my view, for the lack of a better word. Most of the issue is that for the most part said "view" is not palpable: it's the ranges I haven't implemented yet, the I/O I haven't designed yet, the containers I haven't implemented yet, and the threading library we haven't designed yet. At the same time, Tango as defined today itself does not take advantage of D2. So I'd find it odd to ask people at this point whether they'd choose between a library that essentially doesn't exist yet, and one that might improve by going through one more iteration. It's just too early for D2. Andrei

Ok, I see. -JJR
Jan 18 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 This I completely disagree with. 360 degrees :o). Good stuff comes from 
 good vision, not from doing what people think they want (see PHP, 
 American cars, and taking dating advice from female friends).

You're still wrong about American cars! http://www.seifertbros.com/hemicuda.html
Jan 18 2009
prev sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
IUnknown wrote:
 Agree. Which is why I said the problems you are facing seem to be
non-technical. I'm suggesting that the D library developers should pick one and
axe the other. *I* think what more important is to have one single set of
containers in a single style rather than have two separate ones. There is going
to be complaining for sure from the current developers, but in my opinion, the
target of having a single standard library (with core and advanced modules to
suit system/ app programming) is more important than having to make a difficult
choice. 

Totally agree. While I personally prefer the Java-style containers, I'd gladly accept the STL-style containers if it meant unification of Phobos and Tango. Having druntime is nice, sure, but application-level code and high-level libraries will bake the container API into their public interfaces, and any code that uses both the Phobos and Tango libraries would have to perform a zillion tedious conversions. In my mind, the things that need a unified API are (in order of importance): 1. GC and TypeInfo 2. Data structures 3. Algorithms 4. String processing 5. Date & Time 6. IO Everything else (encryption, compression, sockets, regular expressions, could have a totally different API in Tango & Phobos and I wouldn't care much. Having a common runtime (GC and TypeInfo) is a neat trick, but pretty useless if the data structures and algorithms are entirely different. And, while I'm perfectly willing to accept either Java-style or STL-style containers, I'd also really appreciate it if the design anticipates and supports custom implementations (because I almost always end up implementing my own multimaps, multisets, circular queues etc) --benji
Jan 21 2009
next sibling parent Aarti_pl <aarti interia.pl> writes:
Denis Koroskin pisze:
 On Thu, 22 Jan 2009 09:18:52 +0300, Benji Smith 
 <dlanguage benjismith.net> wrote:
 
 IUnknown wrote:
 Agree. Which is why I said the problems you are facing seem to be 
 non-technical. I'm suggesting that the D library developers should 
 pick one and axe the other. *I* think what more important is to have 
 one single set of containers in a single style rather than have two 
 separate ones. There is going to be complaining for sure from the 
 current developers, but in my opinion, the target of having a single 
 standard library (with core and advanced modules to suit system/ app 
 programming) is more important than having to make a difficult choice.

Totally agree. While I personally prefer the Java-style containers, I'd gladly accept the STL-style containers if it meant unification of Phobos and Tango. Having druntime is nice, sure, but application-level code and high-level libraries will bake the container API into their public interfaces, and any code that uses both the Phobos and Tango libraries would have to perform a zillion tedious conversions. In my mind, the things that need a unified API are (in order of importance): 1. GC and TypeInfo 2. Data structures 3. Algorithms 4. String processing 5. Date & Time 6. IO Everything else (encryption, compression, sockets, regular expressions, could have a totally different API in Tango & Phobos and I wouldn't care much. Having a common runtime (GC and TypeInfo) is a neat trick, but pretty useless if the data structures and algorithms are entirely different. And, while I'm perfectly willing to accept either Java-style or STL-style containers, I'd also really appreciate it if the design anticipates and supports custom implementations (because I almost always end up implementing my own multimaps, multisets, circular queues etc) --benji

I think believe we could take advantage of current state of both libraries in D2 - they are both incomplete and being redesigned to fit D2 better. We could revisit both Tango and Phobos, and clean them up by removing outdated modules and modules with same functionality. This will make Phobos really small and much easier to learn. On the other hand, Tango will continue providing all the extended functionality. Here is a list of Phobos modules that I believe could be safely removed: - crc32 and std.md5 - these should be deprecated in favor of tango.io.digest.Crc32 and tango.io.digest.Md5 Tango is better designed and has support for other algoriths (MD2, MD4, SHA256, SHA512, Tiger and more). See http://www.dsource.org/projects/tango/wiki/ChapterEncodingAndCrypto for details. - std.atomics - tango.core.Atomic is superior to it (std.atomics has nothing but CAS anyway). - std.base64 - deprecate in favor of tango.io.encode.Base64 - std.cover - is it supposed to be visible to user? Should it be in Phobos? - std.loader - deprecate in favor of tango.sys.SharedLib - std.bitarray - std.openrj - std.process - merge with tango.sys.Process - std.regexp - buggy, deprecate in favor of tango.text.Regex - std.socket, std.socketstream - deprecate in favor of tango.net.* - std.uni - deprecate in favor of tango.text.Unicode - std.uri - deprecate in favor of tango.net.Uri - std.xml - deprecate in favor of tango.text.xml.* - std.zip and std.zlib - deprecate in favor of tango.io.compress.* In almost *all* cases Tango has cleaner, faster and less buggy implementation of the same functionality. Other modules - does anyone use any of these: std.bitmanip std.bind std.boxer std.outbuffer std.stdint std.syserror std.system ? There are a lot of modules that only exist in Phobos because of some historical reasons or because Walter wrote it. Is it a sufficient reason for them to stay? They are no doubt useful sometimes, but are we going to put everything that is useful sometimes into Phobos? I believe it would be better for everyone to keep Phobos simple and prevent the two libraries from competing by separating the functionality. Once they don't compete anymore, users won't have to worry about what library to use how to stay compatible.

Also my thoughts. Several months ago I send similar proposition to divide libraries responsibilities: - for Phobos - low level API - for Tango - higher level API Stuff which is in both libraries should be designed together by both teams. Andrei is talking about new design for IO in Phobos. Why not to prepare this new design together with Tango people? Some differences between philosophies of libraries should not stop merging. E.g. Phobos uses IO synchronized with C, but Tango is not. Why to divide libraries based on this? I think that there are cases where users would want one approach and also cases where they would want the other. IMHO standard library should have API allowing one or other approach depending on what user wants... So this difference is purely rhetorical... BR Marcin Kuszczak (aarti_pl) www.zapytajmnie.com - my christian site
Jan 22 2009
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Denis Koroskin Wrote:

 I think believe we could take advantage of current state of both libraries in
D2 - they are both incomplete and being redesigned to fit D2 better.
 We could revisit both Tango and Phobos, and clean them up by removing outdated
modules and modules with same functionality. This will make Phobos really small
and much easier to learn.
 
 On the other hand, Tango will continue providing all the extended
functionality.
 
 Here is a list of Phobos modules that I believe could be safely removed:
 
 - crc32 and std.md5 - these should be deprecated in favor of
tango.io.digest.Crc32 and tango.io.digest.Md5
 Tango is better designed and has support for other algoriths (MD2, MD4,
SHA256, SHA512, Tiger and more).
 See http://www.dsource.org/projects/tango/wiki/ChapterEncodingAndCrypto for
details.
 
 - std.atomics - tango.core.Atomic is superior to it (std.atomics has nothing
but CAS anyway).
 - std.base64 - deprecate in favor of tango.io.encode.Base64
 - std.cover - is it supposed to be visible to user? Should it be in Phobos?
 - std.loader - deprecate in favor of tango.sys.SharedLib
 - std.bitarray
 - std.openrj
 - std.process - merge with tango.sys.Process
 - std.regexp - buggy, deprecate in favor of tango.text.Regex
 - std.socket, std.socketstream - deprecate in favor of tango.net.*
 - std.uni - deprecate in favor of tango.text.Unicode
 - std.uri - deprecate in favor of tango.net.Uri
 - std.xml - deprecate in favor of tango.text.xml.*
 - std.zip and std.zlib - deprecate in favor of tango.io.compress.*
 
 In almost *all* cases Tango has cleaner, faster and less buggy implementation
of the same functionality.

That's an interesting list. Without the ability to distribute Phobos and Tango together from the digitalmars.com site, I doubt anything will get dropped from Phobos in favor of what is in Tango. For a combined distribution to ever occur requires a whole lot more coordination between Phobos and Tango that I doubt we'll see for a very long time.
 Other modules - does anyone use any of these:
 std.bitmanip
 std.bind
 std.boxer
 std.outbuffer
 std.stdint
 std.syserror
 std.system
 ?

std.bind is useful for binding data that will change before the delegate is called. I've used bind a lot when doing inter-thread communication with queues of pending commands. I'd also like to use a variant of bit array with fixed sizes, easier initialiation, and uses the SSE instruction set. Right now, neither Phobos nor Tango contains what I want.
Jan 22 2009
parent Jason House <jason.james.house gmail.com> writes:
Denis Koroskin Wrote:

 On Thu, 22 Jan 2009 23:38:04 +0300, Jason House <jason.james.house gmail.com>
wrote:
 
 Denis Koroskin Wrote:

 I think believe we could take advantage of current state of both  
 libraries in D2 - they are both incomplete and being redesigned to fit  
 D2 better.
 We could revisit both Tango and Phobos, and clean them up by removing  
 outdated modules and modules with same functionality. This will make  
 Phobos really small and much easier to learn.

 On the other hand, Tango will continue providing all the extended  
 functionality.

 Here is a list of Phobos modules that I believe could be safely removed:

 - crc32 and std.md5 - these should be deprecated in favor of  
 tango.io.digest.Crc32 and tango.io.digest.Md5
 Tango is better designed and has support for other algoriths (MD2, MD4,  
 SHA256, SHA512, Tiger and more).
 See http://www.dsource.org/projects/tango/wiki/ChapterEncodingAndCrypto  
 for details.

 - std.atomics - tango.core.Atomic is superior to it (std.atomics has  
 nothing but CAS anyway).
 - std.base64 - deprecate in favor of tango.io.encode.Base64
 - std.cover - is it supposed to be visible to user? Should it be in  
 Phobos?
 - std.loader - deprecate in favor of tango.sys.SharedLib
 - std.bitarray
 - std.openrj
 - std.process - merge with tango.sys.Process
 - std.regexp - buggy, deprecate in favor of tango.text.Regex
 - std.socket, std.socketstream - deprecate in favor of tango.net.*
 - std.uni - deprecate in favor of tango.text.Unicode
 - std.uri - deprecate in favor of tango.net.Uri
 - std.xml - deprecate in favor of tango.text.xml.*
 - std.zip and std.zlib - deprecate in favor of tango.io.compress.*

 In almost *all* cases Tango has cleaner, faster and less buggy  
 implementation of the same functionality.

That's an interesting list. Without the ability to distribute Phobos and Tango together from the digitalmars.com site, I doubt anything will get dropped from Phobos in favor of what is in Tango. For a combined distribution to ever occur requires a whole lot more coordination between Phobos and Tango that I doubt we'll see for a very long time.

Is there any problem? Walter gave a special permission to Tango team to distribute DMD with Tango. I believe Tango team can give similar permission to distribute DMD with Tango, too. It ships in a bundle with LDC, at least, and I don't see why it can't ship with DMD. Unless Walter is against it.

If after all the pledges to fix the Tango/Phobos split and a lot of time to take action, eveything should be fixed. When we have to say "can" "could" or other hypothetical terms, it makes me think there is a problem. I am disapponted that druntime can't make its way into D1. Without that, nothing will happen with D1, ever. Meanwhile D2 is at least on hold. Lately, there's been discussion of how the licenses of Phobos and Tango are different. I assume that any legal ambiguity will block distribution by digital mars
 Oh, and Tango2 should exists, of course.
 
 Other modules - does anyone use any of these:
 std.bitmanip
 std.bind
 std.boxer
 std.outbuffer
 std.stdint
 std.syserror
 std.system
 ?

std.bind is useful for binding data that will change before the delegate is called. I've used bind a lot when doing inter-thread communication with queues of pending commands. I'd also like to use a variant of bit array with fixed sizes, easier initialiation, and uses the SSE instruction set. Right now, neither Phobos nor Tango contains what I want.


Jan 23 2009
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:
 IUnknown wrote:
 Regarding Phobos + Tango, the minimum I expect is things like
 containers, algorithm and common math stuff to be in one core module.

This is already bound to be an issue because there is disagreement on how e.g. containers should look like (Java-style vs. STL-style). Which should be chosen? This naturally influences how algorithms are defined. Andrei

The analogy with KDE vs Gnome doesn't seem valid to me -- most libraries will work regardless of which GUI library is chosen. Programmers can still rely on the Posix and C standard libraries. Can we work out the math stuff at least? There's no difference between Phobos and Tango there. All we need is an agreement on common module naming (eg, create core.math). By the way, Andrei, this is exactly the kind of attitude which I was ranting about. There are clear areas of duplicated code (fortunately much of it is in druntime now), and even Tango's containers still seem to be in a state of flux (the old container library is deprecated, and very little of Tango is currently using containers). Everyone -- can we be productive instead of dismissive, please?
Jan 21 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Don wrote:
 Andrei Alexandrescu wrote:
 IUnknown wrote:
 Regarding Phobos + Tango, the minimum I expect is things like
 containers, algorithm and common math stuff to be in one core module.

This is already bound to be an issue because there is disagreement on how e.g. containers should look like (Java-style vs. STL-style). Which should be chosen? This naturally influences how algorithms are defined. Andrei

The analogy with KDE vs Gnome doesn't seem valid to me -- most libraries will work regardless of which GUI library is chosen. Programmers can still rely on the Posix and C standard libraries.

I agree.
 Can we work out the math stuff at least? There's no difference between 
 Phobos and Tango there. All we need is an agreement on common module 
 naming (eg, create core.math).

That would be great. I don't think that's a major issue anyway. If I were you, to be compatible with today's state of affairs, I'd simply put in the makefile the code necessary for switching the module prefixes.
 By the way, Andrei, this is exactly the kind of attitude which I was 
 ranting about. There are clear areas of duplicated code (fortunately 
 much of it is in druntime now), and even Tango's containers still seem 
 to be in a state of flux (the old container library is deprecated, and 
 very little of Tango is currently using containers).
 Everyone -- can we be productive instead of dismissive, please?

I think you're reading significantly more into what I wrote than I meant to put in. Andrei
Jan 21 2009
parent reply Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:
 Don wrote:
 Andrei Alexandrescu wrote:
 IUnknown wrote:
 Regarding Phobos + Tango, the minimum I expect is things like
 containers, algorithm and common math stuff to be in one core module.

This is already bound to be an issue because there is disagreement on how e.g. containers should look like (Java-style vs. STL-style). Which should be chosen? This naturally influences how algorithms are defined. Andrei

The analogy with KDE vs Gnome doesn't seem valid to me -- most libraries will work regardless of which GUI library is chosen. Programmers can still rely on the Posix and C standard libraries.

I agree.
 Can we work out the math stuff at least? There's no difference between 
 Phobos and Tango there. All we need is an agreement on common module 
 naming (eg, create core.math).

That would be great. I don't think that's a major issue anyway. If I were you, to be compatible with today's state of affairs, I'd simply put in the makefile the code necessary for switching the module prefixes.

It means that any code which uses a library based on both Tango and a library based on Phobos will end up with two copies of all of the functions, and they'll have different name mangling etc. You end up with two incompatible Bigints, for example, even though they have identical code inside.
 By the way, Andrei, this is exactly the kind of attitude which I was 
 ranting about. There are clear areas of duplicated code (fortunately 
 much of it is in druntime now), and even Tango's containers still seem 
 to be in a state of flux (the old container library is deprecated, and 
 very little of Tango is currently using containers).
 Everyone -- can we be productive instead of dismissive, please?

I think you're reading significantly more into what I wrote than I meant to put in.

Good to hear.
 
 
 Andrei

Jan 21 2009
next sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Don wrote:
 Andrei Alexandrescu wrote:
 Don wrote:
 Can we work out the math stuff at least? There's no difference 
 between Phobos and Tango there. All we need is an agreement on common 
 module naming (eg, create core.math).

That would be great. I don't think that's a major issue anyway. If I were you, to be compatible with today's state of affairs, I'd simply put in the makefile the code necessary for switching the module prefixes.

It means that any code which uses a library based on both Tango and a library based on Phobos will end up with two copies of all of the functions, and they'll have different name mangling etc. You end up with two incompatible Bigints, for example, even though they have identical code inside.

Interestingly, this might be less of a problem when using LDC. LLVM has an IPO pass to merge identical functions (opt -mergefunc).
Jan 22 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Don wrote:
 Andrei Alexandrescu wrote:
 Don wrote:
 Andrei Alexandrescu wrote:
 IUnknown wrote:
 Regarding Phobos + Tango, the minimum I expect is things like
 containers, algorithm and common math stuff to be in one core module.

This is already bound to be an issue because there is disagreement on how e.g. containers should look like (Java-style vs. STL-style). Which should be chosen? This naturally influences how algorithms are defined. Andrei

The analogy with KDE vs Gnome doesn't seem valid to me -- most libraries will work regardless of which GUI library is chosen. Programmers can still rely on the Posix and C standard libraries.

I agree.
 Can we work out the math stuff at least? There's no difference 
 between Phobos and Tango there. All we need is an agreement on common 
 module naming (eg, create core.math).

That would be great. I don't think that's a major issue anyway. If I were you, to be compatible with today's state of affairs, I'd simply put in the makefile the code necessary for switching the module prefixes.

It means that any code which uses a library based on both Tango and a library based on Phobos will end up with two copies of all of the functions, and they'll have different name mangling etc. You end up with two incompatible Bigints, for example, even though they have identical code inside.

Oh, I see. You want your library to be usable whether the end user prefers Phobos or Tango. But then why not stick it into a namespace of your choosing? Let's say your libraries are general enough to warrant putting them in a common core, but then anyone who defines some library don't have to go to the "core ombudsman" to add it to the common namespace. They'd just create unique namespaces of their own. No? Andrei
Jan 22 2009
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Andrei Alexandrescu wrote:
 Don wrote:
 [snip]

 It means that any code which uses a library based on both Tango and a
 library based on Phobos will end up with two copies of all of the
 functions, and they'll have different name mangling etc. You end up
 with two incompatible Bigints, for example, even though they have
 identical code inside.

Oh, I see. You want your library to be usable whether the end user prefers Phobos or Tango. But then why not stick it into a namespace of your choosing? Let's say your libraries are general enough to warrant putting them in a common core, but then anyone who defines some library don't have to go to the "core ombudsman" to add it to the common namespace. They'd just create unique namespaces of their own. No? Andrei

I think he means this: let's say you're writing app A. A depends on libraries B and C. B depends on Phobos, and C depends on Tango. Both B and C happen to use BigInts or IO or anything else that isn't shared. All of a sudden, you've now got to link in TWO standard libraries instead of just one, each with potentially duplicated code. From personal experience, the alternative isn't much better: writing code that switches between the two. I have an XML library that can use either Phobos or Tango. It does this by implementing all the calls it needs in a shim library, essentially using it's own standard library. It gets really fun when you need to implement some call that's trivial in one library, but really hard in the other. I remember having to build an IO layer so that both Phobos and Tango had the same semantics regarding EOF or something... Urgh. -- Daniel
Jan 22 2009
parent reply Don <nospam nospam.com> writes:
Daniel Keep wrote:
 
 Andrei Alexandrescu wrote:
 Don wrote:
 [snip]

 It means that any code which uses a library based on both Tango and a
 library based on Phobos will end up with two copies of all of the
 functions, and they'll have different name mangling etc. You end up
 with two incompatible Bigints, for example, even though they have
 identical code inside.

prefers Phobos or Tango. But then why not stick it into a namespace of your choosing? Let's say your libraries are general enough to warrant putting them in a common core, but then anyone who defines some library don't have to go to the "core ombudsman" to add it to the common namespace. They'd just create unique namespaces of their own. No? Andrei

I think he means this: let's say you're writing app A. A depends on libraries B and C. B depends on Phobos, and C depends on Tango. Both B and C happen to use BigInts or IO or anything else that isn't shared. All of a sudden, you've now got to link in TWO standard libraries instead of just one, each with potentially duplicated code.

And you can't obtain a BigInt from library B and pass it into library C, since they are different types; even though they have 100% identical source code except for the name.
 
 From personal experience, the alternative isn't much better: writing
 code that switches between the two.
 
 I have an XML library that can use either Phobos or Tango.  It does this
 by implementing all the calls it needs in a shim library, essentially
 using it's own standard library.
 
 It gets really fun when you need to implement some call that's trivial
 in one library, but really hard in the other.  I remember having to
 build an IO layer so that both Phobos and Tango had the same semantics
 regarding EOF or something...
 
 Urgh.
 
   -- Daniel

Jan 22 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Don wrote:
 Daniel Keep wrote:
 Andrei Alexandrescu wrote:
 Don wrote:
 [snip]

 It means that any code which uses a library based on both Tango and a
 library based on Phobos will end up with two copies of all of the
 functions, and they'll have different name mangling etc. You end up
 with two incompatible Bigints, for example, even though they have
 identical code inside.

prefers Phobos or Tango. But then why not stick it into a namespace of your choosing? Let's say your libraries are general enough to warrant putting them in a common core, but then anyone who defines some library don't have to go to the "core ombudsman" to add it to the common namespace. They'd just create unique namespaces of their own. No? Andrei

I think he means this: let's say you're writing app A. A depends on libraries B and C. B depends on Phobos, and C depends on Tango. Both B and C happen to use BigInts or IO or anything else that isn't shared. All of a sudden, you've now got to link in TWO standard libraries instead of just one, each with potentially duplicated code.

And you can't obtain a BigInt from library B and pass it into library C, since they are different types; even though they have 100% identical source code except for the name.

This will partially be solved by structural casts. I have an implementation but haven't put it in phobos yet. Structural casts will allow types that have the same layout to be cast to one another. Of course, that's still not ideal but it's one step forward. Andrei
Jan 22 2009
prev sibling parent Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:
 Don wrote:
 Andrei Alexandrescu wrote:
 Don wrote:
 Andrei Alexandrescu wrote:
 IUnknown wrote:
 Regarding Phobos + Tango, the minimum I expect is things like
 containers, algorithm and common math stuff to be in one core module.

This is already bound to be an issue because there is disagreement on how e.g. containers should look like (Java-style vs. STL-style). Which should be chosen? This naturally influences how algorithms are defined. Andrei

The analogy with KDE vs Gnome doesn't seem valid to me -- most libraries will work regardless of which GUI library is chosen. Programmers can still rely on the Posix and C standard libraries.

I agree.
 Can we work out the math stuff at least? There's no difference 
 between Phobos and Tango there. All we need is an agreement on 
 common module naming (eg, create core.math).

That would be great. I don't think that's a major issue anyway. If I were you, to be compatible with today's state of affairs, I'd simply put in the makefile the code necessary for switching the module prefixes.

It means that any code which uses a library based on both Tango and a library based on Phobos will end up with two copies of all of the functions, and they'll have different name mangling etc. You end up with two incompatible Bigints, for example, even though they have identical code inside.

Oh, I see. You want your library to be usable whether the end user prefers Phobos or Tango. But then why not stick it into a namespace of your choosing? Let's say your libraries are general enough to warrant putting them in a common core, but then anyone who defines some library don't have to go to the "core ombudsman" to add it to the common namespace. They'd just create unique namespaces of their own. No?

That's possible too. Originally, my code was in the 'mathextra' namespace, and I'm somewhat regretting moving it it out. You still need an ombudsman, though, to determine which libraries are standard, and which are not, in order to prevent namespace collisions. Personally, I like the boost model -- all you need is a root level (like 'boost') to act as a namespace protection mechanism, and then a library standardisation policy. But then you have the question as to the organisation of the 'std' namespace -- for example, it contains such obscure stuff as std.openrj which is actually a stand-alone library. (I notice Dennis has just posted some similar sentiments, so I'll stop for now). It could be that all that we need is to create a standard naming policy.
Jan 22 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 22 Jan 2009 09:18:52 +0300, Benji Smith <dlanguage benjismith.net>
wrote:

 IUnknown wrote:
 Agree. Which is why I said the problems you are facing seem to be  
 non-technical. I'm suggesting that the D library developers should pick  
 one and axe the other. *I* think what more important is to have one  
 single set of containers in a single style rather than have two  
 separate ones. There is going to be complaining for sure from the  
 current developers, but in my opinion, the target of having a single  
 standard library (with core and advanced modules to suit system/ app  
 programming) is more important than having to make a difficult choice.

Totally agree. While I personally prefer the Java-style containers, I'd gladly accept the STL-style containers if it meant unification of Phobos and Tango. Having druntime is nice, sure, but application-level code and high-level libraries will bake the container API into their public interfaces, and any code that uses both the Phobos and Tango libraries would have to perform a zillion tedious conversions. In my mind, the things that need a unified API are (in order of importance): 1. GC and TypeInfo 2. Data structures 3. Algorithms 4. String processing 5. Date & Time 6. IO Everything else (encryption, compression, sockets, regular expressions, could have a totally different API in Tango & Phobos and I wouldn't care much. Having a common runtime (GC and TypeInfo) is a neat trick, but pretty useless if the data structures and algorithms are entirely different. And, while I'm perfectly willing to accept either Java-style or STL-style containers, I'd also really appreciate it if the design anticipates and supports custom implementations (because I almost always end up implementing my own multimaps, multisets, circular queues etc) --benji

I think believe we could take advantage of current state of both libraries in D2 - they are both incomplete and being redesigned to fit D2 better. We could revisit both Tango and Phobos, and clean them up by removing outdated modules and modules with same functionality. This will make Phobos really small and much easier to learn. On the other hand, Tango will continue providing all the extended functionality. Here is a list of Phobos modules that I believe could be safely removed: - crc32 and std.md5 - these should be deprecated in favor of tango.io.digest.Crc32 and tango.io.digest.Md5 Tango is better designed and has support for other algoriths (MD2, MD4, SHA256, SHA512, Tiger and more). See http://www.dsource.org/projects/tango/wiki/ChapterEncodingAndCrypto for details. - std.atomics - tango.core.Atomic is superior to it (std.atomics has nothing but CAS anyway). - std.base64 - deprecate in favor of tango.io.encode.Base64 - std.cover - is it supposed to be visible to user? Should it be in Phobos? - std.loader - deprecate in favor of tango.sys.SharedLib - std.bitarray - std.openrj - std.process - merge with tango.sys.Process - std.regexp - buggy, deprecate in favor of tango.text.Regex - std.socket, std.socketstream - deprecate in favor of tango.net.* - std.uni - deprecate in favor of tango.text.Unicode - std.uri - deprecate in favor of tango.net.Uri - std.xml - deprecate in favor of tango.text.xml.* - std.zip and std.zlib - deprecate in favor of tango.io.compress.* In almost *all* cases Tango has cleaner, faster and less buggy implementation of the same functionality. Other modules - does anyone use any of these: std.bitmanip std.bind std.boxer std.outbuffer std.stdint std.syserror std.system ? There are a lot of modules that only exist in Phobos because of some historical reasons or because Walter wrote it. Is it a sufficient reason for them to stay? They are no doubt useful sometimes, but are we going to put everything that is useful sometimes into Phobos? I believe it would be better for everyone to keep Phobos simple and prevent the two libraries from competing by separating the functionality. Once they don't compete anymore, users won't have to worry about what library to use how to stay compatible.
Jan 22 2009
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 22 Jan 2009 23:38:04 +0300, Jason House <jason.james.house gmail.com>
wrote:

 Denis Koroskin Wrote:

 I think believe we could take advantage of current state of both  
 libraries in D2 - they are both incomplete and being redesigned to fit  
 D2 better.
 We could revisit both Tango and Phobos, and clean them up by removing  
 outdated modules and modules with same functionality. This will make  
 Phobos really small and much easier to learn.

 On the other hand, Tango will continue providing all the extended  
 functionality.

 Here is a list of Phobos modules that I believe could be safely removed:

 - crc32 and std.md5 - these should be deprecated in favor of  
 tango.io.digest.Crc32 and tango.io.digest.Md5
 Tango is better designed and has support for other algoriths (MD2, MD4,  
 SHA256, SHA512, Tiger and more).
 See http://www.dsource.org/projects/tango/wiki/ChapterEncodingAndCrypto  
 for details.

 - std.atomics - tango.core.Atomic is superior to it (std.atomics has  
 nothing but CAS anyway).
 - std.base64 - deprecate in favor of tango.io.encode.Base64
 - std.cover - is it supposed to be visible to user? Should it be in  
 Phobos?
 - std.loader - deprecate in favor of tango.sys.SharedLib
 - std.bitarray
 - std.openrj
 - std.process - merge with tango.sys.Process
 - std.regexp - buggy, deprecate in favor of tango.text.Regex
 - std.socket, std.socketstream - deprecate in favor of tango.net.*
 - std.uni - deprecate in favor of tango.text.Unicode
 - std.uri - deprecate in favor of tango.net.Uri
 - std.xml - deprecate in favor of tango.text.xml.*
 - std.zip and std.zlib - deprecate in favor of tango.io.compress.*

 In almost *all* cases Tango has cleaner, faster and less buggy  
 implementation of the same functionality.

That's an interesting list. Without the ability to distribute Phobos and Tango together from the digitalmars.com site, I doubt anything will get dropped from Phobos in favor of what is in Tango. For a combined distribution to ever occur requires a whole lot more coordination between Phobos and Tango that I doubt we'll see for a very long time.

Is there any problem? Walter gave a special permission to Tango team to distribute DMD with Tango. I believe Tango team can give similar permission to distribute DMD with Tango, too. It ships in a bundle with LDC, at least, and I don't see why it can't ship with DMD. Unless Walter is against it. Oh, and Tango2 should exists, of course.
 Other modules - does anyone use any of these:
 std.bitmanip
 std.bind
 std.boxer
 std.outbuffer
 std.stdint
 std.syserror
 std.system
 ?

std.bind is useful for binding data that will change before the delegate is called. I've used bind a lot when doing inter-thread communication with queues of pending commands. I'd also like to use a variant of bit array with fixed sizes, easier initialiation, and uses the SSE instruction set. Right now, neither Phobos nor Tango contains what I want.

Jan 23 2009