Re: Any chance to call Tango as Extended Standard Library
Benji Smith wrote: Don wrote: Lars Ivar Igesund wrote: Don wrote: druntime should certainly not become any bigger (in scope), as that would defeat the purpose of separating the runtime from userspace in the first place. The topic of common userspace functionality should be kept separate from the topic of druntime. I think you are confusing druntime (the project) with the D runtime. druntime includes the gc as well the runtime, though they are seperate. I see no reason why including core modules in the druntime project would destroy the seperation. Really, this is entirely a question of naming. core.XXX seems to me to be the perfect namespace, certainly for the key math modules which I'm most concerned about (std.math/(tango.math.Math, tango.math.IEEE), and possibly also the low-level bigint routines. These are all functionality which is closely tied to the compiler). Totally agree. Although the name 'druntime' implies it'll only contain the runtime, I think it ought to contain all the common functionality that virtually all applications and libraries will absolutely need: the runtime itself, gc, TypeInfo, math, containers (including ranges), algorithms, string processing, date/time, and IO. After the dsource project was created, someone suggested using the name 'd-core' instead--I think it's more appropriate than 'd-runtime'. That aside, I personally see the visible portion of the runtime to be roughly similar to java.lang. Basically, I think it should contain the stuff that's required for a D app to simply load and run, but anything that's sufficiently intrinsic to the language or language philosophy is appropriate as well. In addition to what's already there, I think an argument could be made for a range definition, essential math routines, and probably a few other things. But things that are simply commonly used belong in the standard library. Without those commonalities, any "compatibility" between Phobos and Tango will be purely illusory. True enough. But attempting to include all of the stuff you mentioned above would require design agreement between the Phobos and Tango folks on quite a bit in terms of API philosophy. Whether the commonality is realized within druntime, or within some other low-level common library (like "dcore"), is immaterial to me. And actually, I don't really care whether Phobos and Tango have their own implementations. But there should be an API (interfaces? concepts? some new template-interface mechanism? doesn't matter.) that both Phobos and Tango implement, so that library consumers can seamlessly pass low-level objects between Phobos and Tango dependent libraries. I agree that this is a fine goal. It just isn't a task I have any intention of pursuing, personally. Sean
Re: Any chance to call Tango as Extended Standard Library
Thu, 22 Jan 2009 21:53:02 -0500, Michel Fortin wrote:
> On 2009-01-19 18:11:15 -0500, Sergey Gromov said:
>
>> I think "can't" is a bit strong a statement. Let's see:
>>
>> With opApply:
>>
>> class progressUpdater(Collection)
>> {
>> this(Collection c)
>> {
>> collection_ = c;
>> }
>>
>> int opApply(int delegate(ref ElementType!(Collection)) dg)
>> {
>> composed_ = dg;
>> return collection_.opApply(&fancifier);
>> }
>>
>> private:
>>
>> int fancifier(ref ElementType!(Collection) el)
>> {
>> globalOnProgress();
>> return composed_(el);
>> }
>>
>> Collection collection_;
>> int delegate(ref ElementType!(Collection)) composed_;
>> }
>
> I think it's the same as this:
>
> class progressUpdater(Collection)
> {
> this(Collection c)
> {
> collection_ = c;
> }
>
> int opApply(int delegate(ref ElementType!(Collection)) dg)
> {
> int fancifier(ref ElementType!(Collection) el)
> {
> globalOnProgress();
> return composed_(el);
> }
>
> composed_ = dg;
> return collection_.opApply(&fancifier);
> }
>
> private:
>
> Collection collection_;
> }
>
> Or this:
>
> class progressUpdater(Collection)
> {
> this(Collection c)
> {
> collection_ = c;
> }
>
> int opApply(int delegate(ref ElementType!(Collection)) dg)
> {
> foreach(ref ElementType!(Collection) el; collection_)
> {
> globalOnProgress();
> if (dg(el))
> return 1;
> }
> return 0;
> }
>
> private:
>
> Collection collection_;
> }
Or even this:
class progressUpdater(Collection)
{
this(Collection c)
{
collection_ = c;
}
int opApply(int delegate(ref ElementType!(Collection)) dg)
{
return collection_.opApply(
(ref ElementType!(Collection) el)
{
globalOnProgress();
return dg(el);
}
);
}
private Collection collection_;
}
Re: Any chance to call Tango as Extended Standard Library
Don wrote: Lars Ivar Igesund wrote: Don wrote: druntime should certainly not become any bigger (in scope), as that would defeat the purpose of separating the runtime from userspace in the first place. The topic of common userspace functionality should be kept separate from the topic of druntime. I think you are confusing druntime (the project) with the D runtime. druntime includes the gc as well the runtime, though they are seperate. I see no reason why including core modules in the druntime project would destroy the seperation. Really, this is entirely a question of naming. core.XXX seems to me to be the perfect namespace, certainly for the key math modules which I'm most concerned about (std.math/(tango.math.Math, tango.math.IEEE), and possibly also the low-level bigint routines. These are all functionality which is closely tied to the compiler). Totally agree. Although the name 'druntime' implies it'll only contain the runtime, I think it ought to contain all the common functionality that virtually all applications and libraries will absolutely need: the runtime itself, gc, TypeInfo, math, containers (including ranges), algorithms, string processing, date/time, and IO. Without those commonalities, any "compatibility" between Phobos and Tango will be purely illusory. Whether the commonality is realized within druntime, or within some other low-level common library (like "dcore"), is immaterial to me. And actually, I don't really care whether Phobos and Tango have their own implementations. But there should be an API (interfaces? concepts? some new template-interface mechanism? doesn't matter.) that both Phobos and Tango implement, so that library consumers can seamlessly pass low-level objects between Phobos and Tango dependent libraries. --benji
Re: Any chance to call Tango as Extended Standard Library
Lars Ivar Igesund wrote: Don wrote: John Reimer wrote: Hello Johan, As a user of D primarily and of the standard libraries secondly I see this reluctance to solve the library situation as the single biggest threat to D. It creates a division in the community and an uncertainty of which library to base my own libraries on. If I use one and the other wins the competition I have to redo a lot of work. It's also a headache when distributing code as I don't know which functions and packages I can assume exists. I hear you. But the argument against this would probably be that you would not have to redo all your work... you just start integrating the use of the other (more popular) library in your work (since they have common runtimes). While this is convenient, yet it would seem to be cumbersome. Now projects will have dependencies on both full libraries including the libary that falls from favour (if that in fact happens). On the other hand, it wouldn't be so bad if one of Tango or Phobos became a 3rd-party/extension library (more suitably this should be Tango), in which case it would seem more natural and familiar to use it as an addon to the other library. -JJR The other option (which I would prefer) is for druntime to get bigger, and encompass more of the common code from both. So that both Phobos and Tango became (crucial) extension libraries over a small core. And the bigger that common core becomes, the smaller the library problem becomes. druntime should certainly not become any bigger (in scope), as that would defeat the purpose of separating the runtime from userspace in the first place. The topic of common userspace functionality should be kept separate from the topic of druntime. I think you are confusing druntime (the project) with the D runtime. druntime includes the gc as well the runtime, though they are seperate. I see no reason why including core modules in the druntime project would destroy the seperation. Really, this is entirely a question of naming. core.XXX seems to me to be the perfect namespace, certainly for the key math modules which I'm most concerned about (std.math/(tango.math.Math, tango.math.IEEE), and possibly also the low-level bigint routines. These are all functionality which is closely tied to the compiler).
Re: Any chance to call Tango as Extended Standard Library
Lars Ivar Igesund wrote: druntime should certainly not become any bigger (in scope), as that would defeat the purpose of separating the runtime from userspace in the first place. The topic of common userspace functionality should be kept separate from the topic of druntime. Okay, how about another library with shared Phobos / Tango components that do not fit in the runtime?
Re: Any chance to call Tango as Extended Standard Library
Don wrote: > John Reimer wrote: >> Hello Johan, >> >> >>> As a user of D primarily and of the standard libraries secondly I see >>> this reluctance to solve the library situation as the single biggest >>> threat to D. It creates a division in the community and an uncertainty >>> of which library to base my own libraries on. If I use one and the >>> other wins the competition I have to redo a lot of work. It's also a >>> headache when distributing code as I don't know which functions and >>> packages I can assume exists. >>> >> >> >> I hear you. But the argument against this would probably be that you >> would not have to redo all your work... you just start integrating the >> use of the other (more popular) library in your work (since they have >> common runtimes). While this is convenient, yet it would seem to be >> cumbersome. Now projects will have dependencies on both full libraries >> including the libary that falls from favour (if that in fact happens). >> >> On the other hand, it wouldn't be so bad if one of Tango or Phobos >> became a 3rd-party/extension library (more suitably this should be >> Tango), in which case it would seem more natural and familiar to use it >> as an addon to the other library. >> >> >> -JJR >> >> > The other option (which I would prefer) is for druntime to get bigger, > and encompass more of the common code from both. So that both Phobos and > Tango became (crucial) extension libraries over a small core. And the > bigger that common core becomes, the smaller the library problem becomes. druntime should certainly not become any bigger (in scope), as that would defeat the purpose of separating the runtime from userspace in the first place. The topic of common userspace functionality should be kept separate from the topic of druntime. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Re: Any chance to call Tango as Extended Standard Library
Denis Koroskin Wrote: > On Thu, 22 Jan 2009 23:38:04 +0300, Jason House > 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. > > >
Re: Any chance to call Tango as Extended Standard Library
On Thu, 22 Jan 2009 23:38:04 +0300, Jason House 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.
Re: Any chance to call Tango as Extended Standard Library
On 2009-01-19 18:11:15 -0500, Sergey Gromov said:
I think "can't" is a bit strong a statement. Let's see:
With opApply:
class progressUpdater(Collection)
{
this(Collection c)
{
collection_ = c;
}
int opApply(int delegate(ref ElementType!(Collection)) dg)
{
composed_ = dg;
return collection_.opApply(&fancifier);
}
private:
int fancifier(ref ElementType!(Collection) el)
{
globalOnProgress();
return composed_(el);
}
Collection collection_;
int delegate(ref ElementType!(Collection)) composed_;
}
I think it's the same as this:
class progressUpdater(Collection)
{
this(Collection c)
{
collection_ = c;
}
int opApply(int delegate(ref ElementType!(Collection)) dg)
{
int fancifier(ref ElementType!(Collection) el)
{
globalOnProgress();
return composed_(el);
}
composed_ = dg;
return collection_.opApply(&fancifier);
}
private:
Collection collection_;
}
Or this:
class progressUpdater(Collection)
{
this(Collection c)
{
collection_ = c;
}
int opApply(int delegate(ref ElementType!(Collection)) dg)
{
foreach(ref ElementType!(Collection) el; collection_)
{
globalOnProgress();
if (dg(el))
return 1;
}
return 0;
}
private:
Collection collection_;
}
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: Any chance to call Tango as Extended Standard Library
On Thu, Jan 22, 2009 at 8:13 PM, Stewart Gordon wrote: > Don wrote: > >> >> The other option (which I would prefer) is for druntime to get bigger, and >> encompass more of the common code from both. So that both Phobos and Tango >> became (crucial) extension libraries over a small core. And the bigger that >> common core becomes, the smaller the library problem becomes. > > Up until the point at which somebody decides it's time to develop a library > to rival druntime. And we prevent that from happening by making as many people as possible happy with the development and features of druntime/core. This is exactly what caused the split in libraries in the first place - a sizable contingent of users who _weren't_ happy with the existing library or its development. In the end though, of course there's nothing we can do from stopping people from developing yet another library. But we can at least try to reduce the likelihood of it.
Re: Any chance to call Tango as Extended Standard Library
Don wrote: The other option (which I would prefer) is for druntime to get bigger, and encompass more of the common code from both. So that both Phobos and Tango became (crucial) extension libraries over a small core. And the bigger that common core becomes, the smaller the library problem becomes. Up until the point at which somebody decides it's time to develop a library to rival druntime. Stewart.
Re: Any chance to call Tango as Extended Standard Library
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.
Re: Any chance to call Tango as Extended Standard Library
On Thu, 22 Jan 2009 18:11:02 +0100, Jarrett Billingsley wrote: On Thu, Jan 22, 2009 at 1:53 AM, Alexander Pánek wrote: John Reimer wrote: Don wrote: The other option (which I would prefer) is for druntime to get bigger, and encompass more of the common code from both. So that both Phobos and Tango became (crucial) extension libraries over a small core. And the bigger that common core becomes, the smaller the library problem becomes. Actually, I very much like that idea. And it seems to make sense too. Seconded! That's a nice idea. Thirded. Fourthed! -- Simen
Re: Any chance to call Tango as Extended Standard Library
Sergey Gromov wrote:
Mon, 19 Jan 2009 06:15:06 -0800, Andrei Alexandrescu wrote:
Michel Fortin wrote:
Other possible things involves a rudimentary profiler (checking for the
elapsed time at each loop iteration), or a progress monitoring template
(notifying another thread of the progress of a particular task).
foreach (task; progessUpdater(timeProfiler(listOfTasks)))
{ ... }
You can't compose iteration based on opApply. How would progessUpdater
and timeProfiler look like? This example pretty much transforms your
argument into mine :o).
I think "can't" is a bit strong a statement. Let's see:
With opApply:
class progressUpdater(Collection)
{
this(Collection c)
{
collection_ = c;
}
int opApply(int delegate(ref ElementType!(Collection)) dg)
{
composed_ = dg;
return collection_.opApply(&fancifier);
}
private:
int fancifier(ref ElementType!(Collection) el)
{
globalOnProgress();
return composed_(el);
}
Collection collection_;
int delegate(ref ElementType!(Collection)) composed_;
}
I see. Very ingenious! Reversed flow of control all the way. Thanks.
Andrei
Re: Any chance to call Tango as Extended Standard Library
On Thu, Jan 22, 2009 at 1:53 AM, Alexander Pánek wrote: > John Reimer wrote: >> >> Don wrote: >>> >>> The other option (which I would prefer) is for druntime to get bigger, >>> and encompass more of the common code from both. So that both Phobos >>> and Tango became (crucial) extension libraries over a small core. And >>> the bigger that common core becomes, the smaller the library problem >>> becomes. >> >> Actually, I very much like that idea. And it seems to make sense too. > > Seconded! That's a nice idea. > Thirded.
Re: Any chance to call Tango as Extended Standard Library
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. 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. 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
Re: Any chance to call Tango as Extended Standard Library
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. 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. 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
Re: Any chance to call Tango as Extended Standard Library
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.
Re: Any chance to call Tango as Extended Standard Library
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
Re: Any chance to call Tango as Extended Standard Library
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
Re: Any chance to call Tango as Extended Standard Library
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).
Re: Any chance to call Tango as Extended Standard Library
Denis Koroskin pisze: On Thu, 22 Jan 2009 09:18:52 +0300, Benji Smith 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
Re: Any chance to call Tango as Extended Standard Library
On Thu, 22 Jan 2009 09:18:52 +0300, Benji Smith 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.
Re: Any chance to call Tango as Extended Standard Library
John Reimer wrote: > > Don wrote: The other option (which I would prefer) is for druntime to get bigger, and encompass more of the common code from both. So that both Phobos and Tango became (crucial) extension libraries over a small core. And the bigger that common core becomes, the smaller the library problem becomes. Actually, I very much like that idea. And it seems to make sense too. Seconded! That’s a nice idea.
Re: Any chance to call Tango as Extended Standard Library
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
Re: Any chance to call Tango as Extended Standard Library
Hello Don, John Reimer wrote: Hello Johan, As a user of D primarily and of the standard libraries secondly I see this reluctance to solve the library situation as the single biggest threat to D. It creates a division in the community and an uncertainty of which library to base my own libraries on. If I use one and the other wins the competition I have to redo a lot of work. It's also a headache when distributing code as I don't know which functions and packages I can assume exists. I hear you. But the argument against this would probably be that you would not have to redo all your work... you just start integrating the use of the other (more popular) library in your work (since they have common runtimes). While this is convenient, yet it would seem to be cumbersome. Now projects will have dependencies on both full libraries including the libary that falls from favour (if that in fact happens). On the other hand, it wouldn't be so bad if one of Tango or Phobos became a 3rd-party/extension library (more suitably this should be Tango), in which case it would seem more natural and familiar to use it as an addon to the other library. -JJR The other option (which I would prefer) is for druntime to get bigger, and encompass more of the common code from both. So that both Phobos and Tango became (crucial) extension libraries over a small core. And the bigger that common core becomes, the smaller the library problem becomes. Actually, I very much like that idea. And it seems to make sense too. -JJR
Re: Any chance to call Tango as Extended Standard Library
John Reimer wrote: Hello Johan, As a user of D primarily and of the standard libraries secondly I see this reluctance to solve the library situation as the single biggest threat to D. It creates a division in the community and an uncertainty of which library to base my own libraries on. If I use one and the other wins the competition I have to redo a lot of work. It's also a headache when distributing code as I don't know which functions and packages I can assume exists. I hear you. But the argument against this would probably be that you would not have to redo all your work... you just start integrating the use of the other (more popular) library in your work (since they have common runtimes). While this is convenient, yet it would seem to be cumbersome. Now projects will have dependencies on both full libraries including the libary that falls from favour (if that in fact happens). On the other hand, it wouldn't be so bad if one of Tango or Phobos became a 3rd-party/extension library (more suitably this should be Tango), in which case it would seem more natural and familiar to use it as an addon to the other library. -JJR The other option (which I would prefer) is for druntime to get bigger, and encompass more of the common code from both. So that both Phobos and Tango became (crucial) extension libraries over a small core. And the bigger that common core becomes, the smaller the library problem becomes.
Re: Any chance to call Tango as Extended Standard Library
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
Re: Any chance to call Tango as Extended Standard Library
Hello Johan, As a user of D primarily and of the standard libraries secondly I see this reluctance to solve the library situation as the single biggest threat to D. It creates a division in the community and an uncertainty of which library to base my own libraries on. If I use one and the other wins the competition I have to redo a lot of work. It's also a headache when distributing code as I don't know which functions and packages I can assume exists. I hear you. But the argument against this would probably be that you would not have to redo all your work... you just start integrating the use of the other (more popular) library in your work (since they have common runtimes). While this is convenient, yet it would seem to be cumbersome. Now projects will have dependencies on both full libraries including the libary that falls from favour (if that in fact happens). On the other hand, it wouldn't be so bad if one of Tango or Phobos became a 3rd-party/extension library (more suitably this should be Tango), in which case it would seem more natural and familiar to use it as an addon to the other library. -JJR
Re: Any chance to call Tango as Extended Standard Library
Lars Ivar Igesund wrote: Andrei Alexandrescu wrote: Lars Ivar Igesund wrote: Andrei Alexandrescu wrote: Lars Ivar Igesund wrote: Andrei Alexandrescu wrote: Lars Ivar Igesund wrote: No, you misunderstand. I said safely call, not exceptionally efficient. To me a virtual call would be acceptable. However, at least in my cases, there would normally not be more than one imlemented interface and such it would be a tiny vtable. Ok, so the scope is reducing nicely. We now have a few problems to solve (some details glossed over for simplicity). a) Get from void* to the TypeInfo that's typing that void*. This will involve a search as the void* could point really anywhere, including untyped memory. So we have a core function: TypeInfo fromAddress(void * p); b) Starting from a TypeInfo, get an interface in case the underlying struct implements that interface: Object TypeInfo.QueryInterface(TypeInfo someInterface); c) Finally, given a void* and an interface, invoke a method of that interface: T structCast!(Interface)(p).method(arguments); Since you used template lingo, it looks a bit like compile time functionality, but yes, very close now :) Also (I keep forgetting to mention important details) - I typically see this used in variadic functions, such that the typeinfo already is there. But what are you ultimately trying to accomplish, and why do you must lose all static information since it was just available to the caller? Isn't there a simpler way to achieve your goal (e.g. using the new variadics)? You are essentially asking for full-blown runtime scripting for all structs. Sorry; new variadics? http://www.digitalmars.com/d/2.0/variadic-function-templates.html Your use case suggests you are using the "look, ma, no templates" solution, whereas the new variadics are shown below that section. Right, but the "new variadics" cannot (being templates) be virtual (which at least sometimes is useful). Templates can always forward to non-templates the void* and pointers to functions of interest that know how to handle the void*. The new code in std.format does that. The solution can be easily extended to forward to interfaces that are created and allocated suitably. Essentially what I'm saying is, if you're asking for a feature there should be a reasonably clear picture of the implementation possible attacks and of the various consequences of the tradeoffs involved. I understand it would be nice to have structs automatically offer runtime-queriable interfaces at no per-instance cost, no dynamic allocation, and with free bonus miles, but then that's only a deceptively little part of the story. Andrei
Re: Any chance to call Tango as Extended Standard Library
Andrei Alexandrescu wrote: > Lars Ivar Igesund wrote: >> Andrei Alexandrescu wrote: >> >>> Lars Ivar Igesund wrote: Andrei Alexandrescu wrote: > Lars Ivar Igesund wrote: >> No, you misunderstand. I said safely call, not exceptionally >> efficient. To me a virtual call would be acceptable. However, at >> least in my cases, there would normally not be more than one >> imlemented interface and such it would be a tiny vtable. > Ok, so the scope is reducing nicely. We now have a few problems to > solve (some details glossed over for simplicity). > > a) Get from void* to the TypeInfo that's typing that void*. This > will involve a search as the void* could point really anywhere, > including untyped memory. So we have a core function: > > TypeInfo fromAddress(void * p); > > b) Starting from a TypeInfo, get an interface in case the > underlying struct implements that interface: > > Object TypeInfo.QueryInterface(TypeInfo someInterface); > > c) Finally, given a void* and an interface, invoke a method of that > interface: > > T structCast!(Interface)(p).method(arguments); Since you used template lingo, it looks a bit like compile time functionality, but yes, very close now :) Also (I keep forgetting to mention important details) - I typically see this used in variadic functions, such that the typeinfo already is there. >>> But what are you ultimately trying to accomplish, and why do you must >>> lose all static information since it was just available to the caller? >>> Isn't there a simpler way to achieve your goal (e.g. using the new >>> variadics)? You are essentially asking for full-blown runtime scripting >>> for all structs. >> >> Sorry; new variadics? > > http://www.digitalmars.com/d/2.0/variadic-function-templates.html > > Your use case suggests you are using the "look, ma, no templates" > solution, whereas the new variadics are shown below that section. Right, but the "new variadics" cannot (being templates) be virtual (which at least sometimes is useful). -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Re: Any chance to call Tango as Extended Standard Library
Lars Ivar Igesund wrote: Andrei Alexandrescu wrote: Lars Ivar Igesund wrote: Andrei Alexandrescu wrote: Lars Ivar Igesund wrote: No, you misunderstand. I said safely call, not exceptionally efficient. To me a virtual call would be acceptable. However, at least in my cases, there would normally not be more than one imlemented interface and such it would be a tiny vtable. Ok, so the scope is reducing nicely. We now have a few problems to solve (some details glossed over for simplicity). a) Get from void* to the TypeInfo that's typing that void*. This will involve a search as the void* could point really anywhere, including untyped memory. So we have a core function: TypeInfo fromAddress(void * p); b) Starting from a TypeInfo, get an interface in case the underlying struct implements that interface: Object TypeInfo.QueryInterface(TypeInfo someInterface); c) Finally, given a void* and an interface, invoke a method of that interface: T structCast!(Interface)(p).method(arguments); Since you used template lingo, it looks a bit like compile time functionality, but yes, very close now :) Also (I keep forgetting to mention important details) - I typically see this used in variadic functions, such that the typeinfo already is there. But what are you ultimately trying to accomplish, and why do you must lose all static information since it was just available to the caller? Isn't there a simpler way to achieve your goal (e.g. using the new variadics)? You are essentially asking for full-blown runtime scripting for all structs. Sorry; new variadics? http://www.digitalmars.com/d/2.0/variadic-function-templates.html Your use case suggests you are using the "look, ma, no templates" solution, whereas the new variadics are shown below that section. Andrei
Re: Any chance to call Tango as Extended Standard Library
Andrei Alexandrescu wrote: > Lars Ivar Igesund wrote: >> Andrei Alexandrescu wrote: >> >>> Lars Ivar Igesund wrote: No, you misunderstand. I said safely call, not exceptionally efficient. To me a virtual call would be acceptable. However, at least in my cases, there would normally not be more than one imlemented interface and such it would be a tiny vtable. >>> Ok, so the scope is reducing nicely. We now have a few problems to >>> solve (some details glossed over for simplicity). >>> >>> a) Get from void* to the TypeInfo that's typing that void*. This >>> will involve a search as the void* could point really anywhere, >>> including untyped memory. So we have a core function: >>> >>> TypeInfo fromAddress(void * p); >>> >>> b) Starting from a TypeInfo, get an interface in case the >>> underlying struct implements that interface: >>> >>> Object TypeInfo.QueryInterface(TypeInfo someInterface); >>> >>> c) Finally, given a void* and an interface, invoke a method of that >>> interface: >>> >>> T structCast!(Interface)(p).method(arguments); >> >> Since you used template lingo, it looks a bit like compile time >> functionality, but yes, very close now :) >> >> Also (I keep forgetting to mention important details) - I typically >> see this used in variadic functions, such that the typeinfo already >> is there. > > But what are you ultimately trying to accomplish, and why do you must > lose all static information since it was just available to the caller? > Isn't there a simpler way to achieve your goal (e.g. using the new > variadics)? You are essentially asking for full-blown runtime scripting > for all structs. Sorry; new variadics? -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Re: Any chance to call Tango as Extended Standard Library
Don wrote: > John Reimer wrote: >> Hello dsimcha, >> >>> == Quote from Daniel Keep (daniel.keep.li...@gmail.com)'s article >>> Piotrek wrote: > Lars Ivar Igesund wrote: > >> Tango will stay Tango (and tango.*). The above naming assumes that >> Tango will depend on Phobos, and it will not. >> > I see. > > Cheers > (Note: speaking as merely an infrequent contributor to Tango; my opinion is my own and does not reflect on those of the Master Dancers, or the ruling council of glittery-shoed programmers.) (Warning: semi-rant ahead.) The problem is that Phobos and Tango are diametrically opposed in almost every conceivable way. Bringing them together would be like trying to bring matter and anti-matter together; you're just going to blow yourself up. It's best if you think of Phobos as being Python and Tango as being Java. Phobos implements a relatively flat (if messy) hierarchy of simple, fat classes. For example, IO is done using the Stream interfaces, each one implements all the methods you'd probably need to work with streams. Tango, on the other hand, implements a very deep (if confusing) hierarchy of simple, component interfaces that get plugged together. Unlike Phobos, IO in Tango has many layers and components, each of which is very narrowly defined, allowing you to plug them together however you like. The problem is that neither of these approaches is WRONG. They're both valid and arguably better in certain circumstances. What's more, the continued existence of both shows that there are people who believe in each of them (not necessarily at the same time, but there you go.) So let's say we combined them into std.* and stdex.*. Why is Tango stdex? Why isn't Tango std.* and Phobos stdsimple? Ok, ignoring egos, the problem is that they wouldn't work together anyway. An old favourite of mine is (again, sorry about this) IO. Phobos strives to be compatible with the C IO library; so you can interleave Phobos and C IO calls and it's all gravy. Tango takes C out the back and shoots it before burying it upside-down at a crossroads with a steak through the heart and salting the earth. You CAN mix Tango and C IO calls, but you really have no idea what order the output's going to arrive in. I remember Andrei getting antsy about this a while back; why break compatibility?! Because Tango's IO was faster this way. Neither one of them was 'right' because they both had legitimate points of view. Really, it all boils down to this: there *is no* one right way. Yes, it's more confusing. But it's a problem with programming in general; programming is all about looking at your options and making a decision on the matter. -- Daniel >>> Wow. Excellent analysis. One thing I'd like to add is that Phobos >>> tends to be >>> much more focused on the bleeding edge, with pretty much all >>> development happening >>> on the D2 branch, while Tango is more focused on targeting stable >>> compilers. > >>> Also, another way I would summarize the situation is that Phobos >>> focuses on first >>> making simple operations simple first and foremost, and then worries >>> about making >>> complicated operations possible, while Tango does just the opposite. >> >> I don't know if that is strictly true. In Tango's defense, I believe it >> has tried quite hard to move in the direction of making simple things >> simple even under the restrictions of its own philosophy :). If you >> examine the progression of Tango revisions, there has been a significant >> "cleanup" in progress that appears to be simplifying what was originally >> verbose. >> >>> I've said this before, but I think it's not so bad for D to have two >>> standard libraries with different design philosophies, at least in >>> principle, though the inability to use both side by side on D1 is >>> obviously a bad thing. There are times when I like the Phobos "keep >>> it simple, stupid" approach and times when I want Tango's "everything >>> but the kitchen sink" approach. There are a few things that I think >>> would help a lot here: >>> >> >>> 1. Both Phobos and Tango should adopt these opposite design >>> philosophies, which are true de facto anyhow, officially. This will >>> prevent excessive feature envy and duplication of effort and allow >>> newcomers to determine which is best for their everyday use. >>> >> Like I said, I believe Tango has worked harder at doing this than you >> might think. I don't think Phobos cares to look at the opposite >> philosophy because it really doesn't merge well with it's intended >> goals. Tango can afford some brevity because it started at the verbose >> end. >> >> >>> 2. The creation of druntime so that Phobos and Tango c
Re: Any chance to call Tango as Extended Standard Library
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
Re: Any chance to call Tango as Extended Standard Library
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?
Re: Any chance to call Tango as Extended Standard Library
Lars Ivar Igesund wrote:
Andrei Alexandrescu wrote:
Lars Ivar Igesund wrote:
No, you misunderstand. I said safely call, not exceptionally
efficient. To me a virtual call would be acceptable. However, at
least in my cases, there would normally not be more than one
imlemented interface and such it would be a tiny vtable.
Ok, so the scope is reducing nicely. We now have a few problems to
solve (some details glossed over for simplicity).
a) Get from void* to the TypeInfo that's typing that void*. This
will involve a search as the void* could point really anywhere,
including untyped memory. So we have a core function:
TypeInfo fromAddress(void * p);
b) Starting from a TypeInfo, get an interface in case the
underlying struct implements that interface:
Object TypeInfo.QueryInterface(TypeInfo someInterface);
c) Finally, given a void* and an interface, invoke a method of that
interface:
T structCast!(Interface)(p).method(arguments);
Since you used template lingo, it looks a bit like compile time
functionality, but yes, very close now :)
Also (I keep forgetting to mention important details) - I typically
see this used in variadic functions, such that the typeinfo already
is there.
But what are you ultimately trying to accomplish, and why do you must
lose all static information since it was just available to the caller?
Isn't there a simpler way to achieve your goal (e.g. using the new
variadics)? You are essentially asking for full-blown runtime scripting
for all structs.
And an additional question only semi-related to the above; is it
possible to have a function that works as a variadic function, but
where the number of arguments is restricted to 1 (or 2 or 3 but not
unbounded).
void foo(R..)(R args) if (R.length == 2)
{
...
}
It doesn't work now due to a bug in the compiler, you may want to submit it.
Oh oh, I'm getting into a steam (and even less related ...) -
variadic ref parameters.
That will be fixed.
Andrei
Re: Any chance to call Tango as Extended Standard Library
Lars Ivar Igesund wrote: Steven Schveighoffer wrote: "Lars Ivar Igesund" wrote Steven Schveighoffer wrote: I can't really understand whether it is required to distribute the source code of a derivative work under the Academic Free License, so I don't really understand that. It is not required, AFAIK only LGPL and GPL of the common licenses require that. That is good to hear. Can a statement like this be made on the license page? Or in the license itself? I found it very difficult to discern what was meant, at some point it states that you must provide a copy of the source code, but I wasn't sure how that applies. I thought the license page (.../wiki/License) was pretty clear ... even if the licenses themselves aren't. It’s actually /wiki/LibraryLicense. I’ve created /wiki/License including and displaying the contents of LibraryLicense.
Re: Any chance to call Tango as Extended Standard Library
Bill Baxter wrote: On Wed, Jan 21, 2009 at 6:29 AM, Lars Ivar Igesund wrote: I thought the license page (.../wiki/License) was pretty clear ... even if the licenses themselves aren't. Actually this was something I meant to bring up. I couldn't actually find that page when I was looking for it. I ended up doing a search on the Tango site for "license". I think there should be a link to the license page somewhere on the front page. Right now the word "license" doesn't appear anywhere on that page. --bb The link is on the "about" page.
Re: Any chance to call Tango as Extended Standard Library
Bill Baxter wrote: On Wed, Jan 21, 2009 at 6:29 AM, Lars Ivar Igesund wrote: I thought the license page (.../wiki/License) was pretty clear ... even if the licenses themselves aren't. Actually this was something I meant to bring up. I couldn't actually find that page when I was looking for it. I ended up doing a search on the Tango site for "license". I think there should be a link to the license page somewhere on the front page. Right now the word "license" doesn't appear anywhere on that page. There’s a link on the front page “All Documentation” where you find the link to the “License Agreement” page, but having the latter on the front page wouldn’t be a bad idea either, I suppose.
Re: Any chance to call Tango as Extended Standard Library
On Wed, Jan 21, 2009 at 6:29 AM, Lars Ivar Igesund wrote: > I thought the license page (.../wiki/License) was pretty clear ... even if > the licenses themselves aren't. Actually this was something I meant to bring up. I couldn't actually find that page when I was looking for it. I ended up doing a search on the Tango site for "license". I think there should be a link to the license page somewhere on the front page. Right now the word "license" doesn't appear anywhere on that page. --bb
Re: Any chance to call Tango as Extended Standard Library
Steven Schveighoffer wrote: > "Lars Ivar Igesund" wrote >> Steven Schveighoffer wrote: >>> I can't really understand whether it is required to distribute the >>> source code of a derivative work under the Academic Free License, so I >>> don't really >>> understand that. >> >> It is not required, AFAIK only LGPL and GPL of the common licenses >> require that. > > That is good to hear. Can a statement like this be made on the license > page? Or in the license itself? I found it very difficult to discern > what was meant, at some point it states that you must provide a copy of > the source code, but I wasn't sure how that applies. I thought the license page (.../wiki/License) was pretty clear ... even if the licenses themselves aren't. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Re: Any chance to call Tango as Extended Standard Library
"Lars Ivar Igesund" wrote > Steven Schveighoffer wrote: >> I can't really understand whether it is required to distribute the source >> code of a derivative work under the Academic Free License, so I don't >> really >> understand that. > > It is not required, AFAIK only LGPL and GPL of the common licenses require > that. That is good to hear. Can a statement like this be made on the license page? Or in the license itself? I found it very difficult to discern what was meant, at some point it states that you must provide a copy of the source code, but I wasn't sure how that applies. Sorry for the confusion... -Steve
Re: Any chance to call Tango as Extended Standard Library
Steven Schveighoffer wrote: > "Lars Ivar Igesund" wrote >> Steven Schveighoffer wrote: >> >>> "Piotrek" wrote Hello! It's just an idea. After reading about issues on disallowing DWT to stay in standardization area (Anomaly on Wiki4D GuiLibraries page) some question appeared in my mind. For propaganda sake isn't it better to not make such a big division between phobos and tango in the module naming? Logically: phobos -> std tango -> stdex (not tango -> tango) >>> >>> Let's not forget the licensing issues. Tango is incompatible with some >>> developers license wise, as you must include attribution for Tango in >>> any >>> derivative works (i.e. compiled binaries). Phobos has a less >>> restrictive >>> opt-in policy. I think Walter intends to keep it that way, at least for >>> DMD. Note that other compilers are free to use Tango or their own >>> standard library, the D spec is pretty free from library references. >> >> Sorry, where do you find this attribution clause? The only two >> restrictions put on Tango source is: >> >> * You cannot relicense the source - can't possibly be a problem to anyone >> * You cannot take the source and say you wrote it (unless you actually >> did) - not a problem for a single person unless he'd like to be >> dishonest. >> >> Saying that Tango is license-encumbered in any way is a gross >> misunderstanding. > > Sorry if I'm spreading misinformation, but I understood this clause in the > BSD license to mean that any binary distribution must contain attribution: > > "Redistributions in binary form must reproduce the above copyright notice, > this list of conditions and the following disclaimer in the documentation > and/or other materials provided with the distribution." > > The mentioned copyright notice being "Copyright (c) 2004-2008, Tango > contributors All rights reserved." > > As D is statically compiled, any application which uses Tango is > effectively > a binary distribution of it. At least that's what I interpret it as. How > do youi interpret the above line? You are correct about the BSD license, but where you are wrong is the fact that you as a user choose which of the two available licenses you wish to agree with. BSD with the binary clause is necessary for compatibility with (L)GPL, whereas APL, stands for completely free binary use, but the source restriction that you cannot remove the name of the authors (although you can freely augment the list if that is a correct picture). So it is not both licenses, but the one that suits you. > Conversely, the Phobos license's clause is: > > "The origin of this software must not be misrepresented; you must not > claim that you wrote the original software. If you use this software in a > product, an acknowledgment in the product documentation would be > appreciated but is not required." In practice this should be the same as the APL, only that the APL is written in legalese for better or worse. > I can't really understand whether it is required to distribute the source > code of a derivative work under the Academic Free License, so I don't > really > understand that. It is not required, AFAIK only LGPL and GPL of the common licenses require that. > Maybe that is the license you can use for distributing > binaries without attribution? Yes. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Re: Any chance to call Tango as Extended Standard Library
"Lars Ivar Igesund" wrote > Steven Schveighoffer wrote: > >> "Piotrek" wrote >>> Hello! >>> >>> It's just an idea. After reading about issues on disallowing DWT to stay >>> in standardization area (Anomaly on Wiki4D GuiLibraries page) some >>> question appeared in my mind. For propaganda sake isn't it better to not >>> make such a big division between phobos and tango in the module naming? >>> Logically: >>> >>> phobos -> std >>> tango -> stdex (not tango -> tango) >> >> Let's not forget the licensing issues. Tango is incompatible with some >> developers license wise, as you must include attribution for Tango in any >> derivative works (i.e. compiled binaries). Phobos has a less restrictive >> opt-in policy. I think Walter intends to keep it that way, at least for >> DMD. Note that other compilers are free to use Tango or their own >> standard library, the D spec is pretty free from library references. > > Sorry, where do you find this attribution clause? The only two > restrictions put on Tango source is: > > * You cannot relicense the source - can't possibly be a problem to anyone > * You cannot take the source and say you wrote it (unless you actually > did) - not a problem for a single person unless he'd like to be dishonest. > > Saying that Tango is license-encumbered in any way is a gross > misunderstanding. Sorry if I'm spreading misinformation, but I understood this clause in the BSD license to mean that any binary distribution must contain attribution: "Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution." The mentioned copyright notice being "Copyright (c) 2004-2008, Tango contributors All rights reserved." As D is statically compiled, any application which uses Tango is effectively a binary distribution of it. At least that's what I interpret it as. How do youi interpret the above line? Conversely, the Phobos license's clause is: "The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required." Which I interpret to mean that you cannot misrepresent that you wrote Phobos, but it is appreciated if you give Digital Mars credit for it in your application. I can't really understand whether it is required to distribute the source code of a derivative work under the Academic Free License, so I don't really understand that. Maybe that is the license you can use for distributing binaries without attribution? I'd love to be wrong, because that would mean Tango is a lot more open than I originally thought. -Steve
Re: Any chance to call Tango as Extended Standard Library
Steven Schveighoffer wrote: > "Piotrek" wrote >> Hello! >> >> It's just an idea. After reading about issues on disallowing DWT to stay >> in standardization area (Anomaly on Wiki4D GuiLibraries page) some >> question appeared in my mind. For propaganda sake isn't it better to not >> make such a big division between phobos and tango in the module naming? >> Logically: >> >> phobos -> std >> tango -> stdex (not tango -> tango) > > Let's not forget the licensing issues. Tango is incompatible with some > developers license wise, as you must include attribution for Tango in any > derivative works (i.e. compiled binaries). Phobos has a less restrictive > opt-in policy. I think Walter intends to keep it that way, at least for > DMD. Note that other compilers are free to use Tango or their own > standard library, the D spec is pretty free from library references. Sorry, where do you find this attribution clause? The only two restrictions put on Tango source is: * You cannot relicense the source - can't possibly be a problem to anyone * You cannot take the source and say you wrote it (unless you actually did) - not a problem for a single person unless he'd like to be dishonest. Saying that Tango is license-encumbered in any way is a gross misunderstanding. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Re: Any chance to call Tango as Extended Standard Library
Don wrote: > Steven Schveighoffer wrote: >> Let's not forget the licensing issues. Tango is incompatible with some >> developers license wise, as you must include attribution for Tango in any >> derivative works (i.e. compiled binaries). > > Are you sure? Where is that written down? I can't find that anywhere in > the Tango license. Steve is wrong in this matter. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Re: Any chance to call Tango as Extended Standard Library
dsimcha Wrote: > Yeah, but we also want decent performance and even compared to opApply, > coroutines/fibers are slow as molasses in January at the North Pole during the > last Ice Age. One type of coroutine optimization was mentioned previously on this list: http://www.digitalmars.com/d/archives/digitalmars/D/Coroutine_s_Communication_70713.html I'm sure that it's possible to optimize coroutines such that they require less restoring of the stack, or flattening into inline functions. I'm also going to guess that this style of optimization won't make it into dmd for a very long time. I'd much prefer to quickly write a bug-free coroutine ranges and then go back and optimize those that show up in the profiler as bottlenecks.
Re: Any chance to call Tango as Extended Standard Library
On Tue, Jan 20, 2009 at 12:50 PM, Lars Ivar Igesund wrote: >>> There doesn't really need to be anything wrong with them. What's wrong >>> with head/toe? >> >> It sounds stupid. > > Wholeheartedly agree. Agreed too, what's wrong with first/last? They're completely obvious and have no connotations.
Re: Any chance to call Tango as Extended Standard Library
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article > "Sean Kelly" wrote > > Steven Schveighoffer wrote: > >> "Don" wrote > >>> Bill Baxter wrote: > On Tue, Jan 20, 2009 at 3:00 PM, Don wrote: > > Steven Schveighoffer wrote: > >> Let's not forget the licensing issues. Tango is incompatible with > >> some > >> developers license wise, as you must include attribution for Tango in > >> any > >> derivative works (i.e. compiled binaries). > > Are you sure? Where is that written down? I can't find that anywhere > > in the > > Tango license. > Probably this: > > 6. Attribution Rights. You must retain, in the Source Code of any > Derivative Works that You create, all copyright, patent, or trademark > notices from the Source Code of the Original Work, as well as any > notices of licensing and any descriptive text identified therein as an > "Attribution Notice." You must cause the Source Code for any > Derivative Works that You create to carry a prominent Attribution > Notice reasonably calculated to inform recipients that You have > modified the Original Work. > > I think it's just saying you can't remove stuff from the source code > that says who wrote it. But it's got a thick legal accent that's a > little difficult to understand. > >>> Yes, it explicitly states that it's source code-only requirement. > >>> Perhaps the page should include an approximate explanation, to remove > >>> confusion > >> > >> I'm not a lawyer, but I think that the artistic license requires source > >> redistribution (I agree the license is difficult to comprehend), whereas > >> the BSD style license requires attribution with binaries. So either way, > >> you must provide attribution. Some companies may frown upon that, > >> especially when we're talking about a standard library. > > > > I've read the BSD license very carefully and I think it only requires > > attribution with binary distributions of the library, not apps written > > with the library. If I'm wrong I'd love to know, because druntime is > > currently BSD licensed (something I've been meaning to reconsider). > As D currently is statically linked, any application is a binary > distribution of the library. However, even with shared libraries, I believe > it is still considered a binary distribution if your application uses the > library (as your code needs the dynamic library to run). This is why the > LGPL exists. I don't know if there is an equivalent BSD version. > Again, not a lawyer :) You don't need to be :-). People's perception of a license is as important as what it means in fact. None of this is an issue for the DMD distribution because I've granted Walter permission to distribute druntime under the Phobos license, but it's something I want to take care of regardless. I may just make the darn thing public domain to save myself the hassle of finding a license everyone is happy with. Sean
Re: Any chance to call Tango as Extended Standard Library
Andrei Alexandrescu wrote: > Lars Ivar Igesund wrote: >> No, you misunderstand. I said safely call, not exceptionally >> efficient. To me a virtual call would be acceptable. However, at >> least in my cases, there would normally not be more than one >> imlemented interface and such it would be a tiny vtable. > > Ok, so the scope is reducing nicely. We now have a few problems to solve > (some details glossed over for simplicity). > > a) Get from void* to the TypeInfo that's typing that void*. This will > involve a search as the void* could point really anywhere, including > untyped memory. So we have a core function: > > TypeInfo fromAddress(void * p); > > b) Starting from a TypeInfo, get an interface in case the underlying > struct implements that interface: > > Object TypeInfo.QueryInterface(TypeInfo someInterface); > > c) Finally, given a void* and an interface, invoke a method of that > interface: > > T structCast!(Interface)(p).method(arguments); Since you used template lingo, it looks a bit like compile time functionality, but yes, very close now :) Also (I keep forgetting to mention important details) - I typically see this used in variadic functions, such that the typeinfo already is there. And an additional question only semi-related to the above; is it possible to have a function that works as a variadic function, but where the number of arguments is restricted to 1 (or 2 or 3 but not unbounded). Oh oh, I'm getting into a steam (and even less related ...) - variadic ref parameters. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Re: Any chance to call Tango as Extended Standard Library
Christopher Wright wrote: > Walter Bright wrote: >> Yigal Chripun wrote: >>> Walter Bright wrote: Lars Ivar Igesund wrote: > toe() ?! tail() good, rear() not so good, toe() sucks. tail() is no good because it has a well-established meaning in programming of being everything but the first element of a list. I just didn't like rear(), as it is not normally thought of as the opposite of head(). >>> >>> What was the reason for the use of body parts in the first place? >>> What's wrong with: >>> a) begin, end >>> b) start, finish >>> c) initial, final >>> d) first, last >>> etc... >> >> >> There doesn't really need to be anything wrong with them. What's wrong >> with head/toe? > > It sounds stupid. Wholeheartedly agree. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Re: Any chance to call Tango as Extended Standard Library
Steven Schveighoffer wrote: > "Jason House" wrote >> Walter Bright wrote: >> >>> Druntime is there, and it's up to the Tango team now. >> >> As I understand it, the biggest fear of the Tango team is to make an >> official D2 version and then have to chase after a moving standard. If >> an official port of Tango 0.99.7 was ported to work with dmd v2.023 how >> willing would you be to ensure that the D2 Tango was functional prior to >> new releases of dmd? I don't necessarily mean that you personally hack >> at Tango D2 for every release with breaking changes but rather that you >> have people lined up to compile and run unit tests, and fix problems >> prior to each release? > > As far as I know, Walter has stated that he is willing to issue a quick > fix > release for easily fixed bugs that hurt Tango. This already happens with > the D1 releases, and I'm sure he'd extend that courtesy for D2 releases > once > Tango D2 is relatively stable. I agree with Walter that the ball is fully > in Tango's court. > > D2 not being stable is probably the largest reason that most of the Tango > devs aren't yet interested, but it doesn't stop some of us from trying :) > Probably the largest hurdle right now is const-ifying all of Tango. Most > of the time, this doesn't just imply slapping a const or immutable label > on something, but really rethinking how a particular module is implemented > to > cater to const properly. Thankfully, however, const is now a stable > target. Once pure/shared/unshared gets introduced, it will probably > require more effort, but probably not as much as with const. There is also the question of how SafeD should be catered for. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Re: Any chance to call Tango as Extended Standard Library
"Sean Kelly" wrote > Steven Schveighoffer wrote: >> "Don" wrote >>> Bill Baxter wrote: On Tue, Jan 20, 2009 at 3:00 PM, Don wrote: > Steven Schveighoffer wrote: >> Let's not forget the licensing issues. Tango is incompatible with >> some >> developers license wise, as you must include attribution for Tango in >> any >> derivative works (i.e. compiled binaries). > Are you sure? Where is that written down? I can't find that anywhere > in the > Tango license. Probably this: 6. Attribution Rights. You must retain, in the Source Code of any Derivative Works that You create, all copyright, patent, or trademark notices from the Source Code of the Original Work, as well as any notices of licensing and any descriptive text identified therein as an "Attribution Notice." You must cause the Source Code for any Derivative Works that You create to carry a prominent Attribution Notice reasonably calculated to inform recipients that You have modified the Original Work. I think it's just saying you can't remove stuff from the source code that says who wrote it. But it's got a thick legal accent that's a little difficult to understand. >>> Yes, it explicitly states that it's source code-only requirement. >>> Perhaps the page should include an approximate explanation, to remove >>> confusion >> >> I'm not a lawyer, but I think that the artistic license requires source >> redistribution (I agree the license is difficult to comprehend), whereas >> the BSD style license requires attribution with binaries. So either way, >> you must provide attribution. Some companies may frown upon that, >> especially when we're talking about a standard library. > > I've read the BSD license very carefully and I think it only requires > attribution with binary distributions of the library, not apps written > with the library. If I'm wrong I'd love to know, because druntime is > currently BSD licensed (something I've been meaning to reconsider). As D currently is statically linked, any application is a binary distribution of the library. However, even with shared libraries, I believe it is still considered a binary distribution if your application uses the library (as your code needs the dynamic library to run). This is why the LGPL exists. I don't know if there is an equivalent BSD version. Again, not a lawyer :) -steve
Re: Any chance to call Tango as Extended Standard Library
Steven Schveighoffer wrote: "Don" wrote Bill Baxter wrote: On Tue, Jan 20, 2009 at 3:00 PM, Don wrote: Steven Schveighoffer wrote: Let's not forget the licensing issues. Tango is incompatible with some developers license wise, as you must include attribution for Tango in any derivative works (i.e. compiled binaries). Are you sure? Where is that written down? I can't find that anywhere in the Tango license. Probably this: 6. Attribution Rights. You must retain, in the Source Code of any Derivative Works that You create, all copyright, patent, or trademark notices from the Source Code of the Original Work, as well as any notices of licensing and any descriptive text identified therein as an "Attribution Notice." You must cause the Source Code for any Derivative Works that You create to carry a prominent Attribution Notice reasonably calculated to inform recipients that You have modified the Original Work. I think it's just saying you can't remove stuff from the source code that says who wrote it. But it's got a thick legal accent that's a little difficult to understand. Yes, it explicitly states that it's source code-only requirement. Perhaps the page should include an approximate explanation, to remove confusion I'm not a lawyer, but I think that the artistic license requires source redistribution (I agree the license is difficult to comprehend), whereas the BSD style license requires attribution with binaries. So either way, you must provide attribution. Some companies may frown upon that, especially when we're talking about a standard library. I've read the BSD license very carefully and I think it only requires attribution with binary distributions of the library, not apps written with the library. If I'm wrong I'd love to know, because druntime is currently BSD licensed (something I've been meaning to reconsider). Sean
Re: Any chance to call Tango as Extended Standard Library
"John Reimer" wrote > Hello Steven, >> I don't see Tango and Phobos becoming more like one or the other, but >> as others have said, there are definite sections of code that can be >> used from both without interference. I/O is not one of them, and I >> don't see that changing. But due to the open source nature, you can >> port or re-implement features of one library into the other, so while >> you may be choosing between two different styles, you shouldn't have >> to choose one or the other for functionality. >> >> I also don't think this is a bad thing. One of two things will >> happen. Either one library totally dominates the other, and eventually >> everyone starts using the more popular one (the Beta/VHS route), or >> both libraries flourish, and due to the common runtime, can be used >> concurrently in projects (the KDE/GNOME route). Either way, I don't >> see the current rift between Tango/Phobos being a major detriment to >> D. It will be short-lived IMO. >> >> -Steve >> > > > A fair analysis, but I think incomplete. Once again, the problem has more > to do with the perception of new users and outsiders. I believe those of > is in here, those of us who have frustrated and agonized over D over the > last few years are going to be in a much better position of accepting the > situation as it develops: we've grown with it, so our sympathies are well > rooted -- we may very much enjoy having the option of using either of or > both of two great libraries. I can easily agree that your analysis has > some sense to it because of that. > > But, as I said before, the hardest part remains in finding a method to > promote it as a "good thing" to everyone else who has no real emotional > attatchment to the language, those who see learning a language as a > synonymous with learning one "standard" library (because that seems to be > the general history of programming languages). Maybe I'm wrong about this > one (I hope I am wrong, and you are right), but I don't think it's wise to > completely discredit the possibility of a problem in having two popular > libraries at the core of D 2.0. If the libraries do go the Beta/VHS > route... well that's just a mercy for D. > > Still trying to think positively, of course. :) Keep thinking positively :) There will always be naysayers, people who think D sucks, no matter how many of their objections you fix, they will find something else to gripe about. There's not much you can do about those people. The ones I am interested in convincing are those who turn to D to fill a need, such as "C++ sucks, I wonder if there's something better", or "I like language X, but I need something that compiles to native code", or whatever the reason. These are the people who are willing to invest the time necessary to learn the core language. If those people, after learning D and about the standard library situation still turn away, then there would be something wrong. But I don't think we are in that situation. Most of the people in this newsgroup are in that category and have stuck it out and want to make D work. Every once in a while, a fierce Phobos vs. Tango debate arises, and it sucks so much time out of people that they are sure it is the main reason people don't like D. When you start using D, you pick a library, and most likely stick to it. There are plenty of resources that work for both the libraries, that I don't think it's that terrible. There are so many other holes in the D regime that I think the fact that you have a choice between two standard libraries is the least of our concern. How about a good integrated IDE/Compiler/Debugger? A visual GUI editor? A better doc system? And most of all an EASY way to install such tools. Following 18 different web pages on unpacking zip files and installing source control systems does not foster new use. I'd say the issue brought up about dsource considered harmful is a huge legitimate deterrent. It takes a long time to scour through all the abandoned projects to find out if the functionality you're looking for is implemented and maintained or not. I know at least one newbie that I helped learn D on IRC from knowing only Python that decided to implement 2 projects that had already been done but were buried in dsource somewhere. Me, I don't care about the library debate, I've already picked Tango as my standard library. I don't care if it's not the standard library. I don't care about the brand name, as long as it does what I need it to do. I've moved on to more important tasks. If other people like Phobos, fine, it doesn't bother me at all. I don't need to have a battle about it. I just want to write code and have it work. And Tango helps me do that better, so that was my choice. I feel like this debate about which standard library wears the official crown is useless noise. No offense to the OP, but this is a never-ending loop that just seems to take up
Re: Any chance to call Tango as Extended Standard Library
"Don" wrote > Bill Baxter wrote: >> On Tue, Jan 20, 2009 at 3:00 PM, Don wrote: >>> Steven Schveighoffer wrote: Let's not forget the licensing issues. Tango is incompatible with some developers license wise, as you must include attribution for Tango in any derivative works (i.e. compiled binaries). >>> Are you sure? Where is that written down? I can't find that anywhere in >>> the >>> Tango license. >> >> Probably this: >> >> 6. Attribution Rights. You must retain, in the Source Code of any >> Derivative Works that You create, all copyright, patent, or trademark >> notices from the Source Code of the Original Work, as well as any >> notices of licensing and any descriptive text identified therein as an >> "Attribution Notice." You must cause the Source Code for any >> Derivative Works that You create to carry a prominent Attribution >> Notice reasonably calculated to inform recipients that You have >> modified the Original Work. >> >> I think it's just saying you can't remove stuff from the source code >> that says who wrote it. But it's got a thick legal accent that's a >> little difficult to understand. > > Yes, it explicitly states that it's source code-only requirement. > Perhaps the page should include an approximate explanation, to remove > confusion I'm not a lawyer, but I think that the artistic license requires source redistribution (I agree the license is difficult to comprehend), whereas the BSD style license requires attribution with binaries. So either way, you must provide attribution. Some companies may frown upon that, especially when we're talking about a standard library. I'm not saying it should change, but that is one other reason that I think Walter has not considered adopting Tango as *the* standard library. -Steve
Re: Any chance to call Tango as Extended Standard Library
Bill Baxter wrote: On Tue, Jan 20, 2009 at 3:00 PM, Don wrote: Steven Schveighoffer wrote: Let's not forget the licensing issues. Tango is incompatible with some developers license wise, as you must include attribution for Tango in any derivative works (i.e. compiled binaries). Are you sure? Where is that written down? I can't find that anywhere in the Tango license. Probably this: 6. Attribution Rights. You must retain, in the Source Code of any Derivative Works that You create, all copyright, patent, or trademark notices from the Source Code of the Original Work, as well as any notices of licensing and any descriptive text identified therein as an "Attribution Notice." You must cause the Source Code for any Derivative Works that You create to carry a prominent Attribution Notice reasonably calculated to inform recipients that You have modified the Original Work. I think it's just saying you can't remove stuff from the source code that says who wrote it. But it's got a thick legal accent that's a little difficult to understand. Yes, it explicitly states that it's source code-only requirement. Perhaps the page should include an approximate explanation, to remove confusion
Re: Any chance to call Tango as Extended Standard Library
On Tue, Jan 20, 2009 at 3:00 PM, Don wrote: > Steven Schveighoffer wrote: >> >> Let's not forget the licensing issues. Tango is incompatible with some >> developers license wise, as you must include attribution for Tango in any >> derivative works (i.e. compiled binaries). > > Are you sure? Where is that written down? I can't find that anywhere in the > Tango license. Probably this: 6. Attribution Rights. You must retain, in the Source Code of any Derivative Works that You create, all copyright, patent, or trademark notices from the Source Code of the Original Work, as well as any notices of licensing and any descriptive text identified therein as an "Attribution Notice." You must cause the Source Code for any Derivative Works that You create to carry a prominent Attribution Notice reasonably calculated to inform recipients that You have modified the Original Work. I think it's just saying you can't remove stuff from the source code that says who wrote it. But it's got a thick legal accent that's a little difficult to understand. --bb
Re: Any chance to call Tango as Extended Standard Library
Jason House wrote: Walter Bright wrote: Druntime is there, and it's up to the Tango team now. As I understand it, the biggest fear of the Tango team is to make an official D2 version and then have to chase after a moving standard. If an official port of Tango 0.99.7 was ported to work with dmd v2.023 how willing would you be to ensure that the D2 Tango was functional prior to new releases of dmd? I don't necessarily mean that you personally hack at Tango D2 for every release with breaking changes but rather that you have people lined up to compile and run unit tests, and fix problems prior to each release? Prior to a release, I send it around to a few people who build and check Tango and a couple other things against it. If the answer to that is yes, I'd be happy to sign up as a tester/fixer. I can guarantee that I won't be able to do a large number of fixes before a release, but would be able to do some. For most releases, that may be enough. For big breaking changes, we'd need several tester/fixer people. I also can't do a D2 + druntime port. I think there's already a pre-druntime port of Tango to D2. I doubt I could do that job, and won't sign up for it. I also won't sign up for porting new Tango functionality to D2 either. Even with all of these restrictions, I believe that this could work for the next year or two while D2 solidifies its design. I'd absolutely love to see this, which is why I'm willing to help maintain it. Maybe there will be other inspired individuals who would do the initial Tango D2 port and others who may periodically update D2 Tango to match the latest and greatest Tango D1 release. I (and others) keep Phobos2 up to date with every iteration of D2. It hasn't been much work, primarily because I avoid making changes in D2 that will silently break code. So when things break, they break noisily and are easy to fix. Also contributing to the ease of keeping it up to date is a good set of unittests, although they could be better still. Even the simplest of unit tests save boatloads of grief down the line. I've got plenty of experience with them now . I'm sure the Tango team will welcome your help!
Re: Any chance to call Tango as Extended Standard Library
Steven Schveighoffer wrote: Let's not forget the licensing issues. Tango is incompatible with some developers license wise, as you must include attribution for Tango in any derivative works (i.e. compiled binaries). Are you sure? Where is that written down? I can't find that anywhere in the Tango license.
Re: Any chance to call Tango as Extended Standard Library
Hello Steven, "Piotrek" wrote Hello! It's just an idea. After reading about issues on disallowing DWT to stay in standardization area (Anomaly on Wiki4D GuiLibraries page) some question appeared in my mind. For propaganda sake isn't it better to not make such a big division between phobos and tango in the module naming? Logically: phobos -> std tango -> stdex (not tango -> tango) Let's not forget the licensing issues. Tango is incompatible with some developers license wise, as you must include attribution for Tango in any derivative works (i.e. compiled binaries). Phobos has a less restrictive opt-in policy. I think Walter intends to keep it that way, at least for DMD. Note that other compilers are free to use Tango or their own standard library, the D spec is pretty free from library references. With regards to Tango for D2. It is going to happen. It may not be tomorrow, but it will probably be done this year. To answer some questions throughout this discussion, it will look similar to Tango/D1, but will utilize many of the features of D2, as well as obey the requirements. For example, it's not simply going to cast away const to keep the implementation closer to D1. So it will look different than Tango/D1 and most likely, will not be one code base. Which means, people will have to maintain both, which is no small feat. But it can (and will) be done. I like D2 too much to not do it :) The Tango D2 branch currently in SVN compiles and runs on Linux DMD 2.019. We have basic functionality for many of the examples, but not all unit tests pass. However, it should be usable to test simple code. So far, we have ported completely tango.core and tango.util.log. We have yet to incorporate druntime, as I didn't want to tackle issues that might be in druntime as well as porting issues. I think I will try to upgrade to 2.023, as it seems druntime/compiler interaction is getting a lot more stable, and then continue porting. I don't see Tango and Phobos becoming more like one or the other, but as others have said, there are definite sections of code that can be used from both without interference. I/O is not one of them, and I don't see that changing. But due to the open source nature, you can port or re-implement features of one library into the other, so while you may be choosing between two different styles, you shouldn't have to choose one or the other for functionality. I also don't think this is a bad thing. One of two things will happen. Either one library totally dominates the other, and eventually everyone starts using the more popular one (the Beta/VHS route), or both libraries flourish, and due to the common runtime, can be used concurrently in projects (the KDE/GNOME route). Either way, I don't see the current rift between Tango/Phobos being a major detriment to D. It will be short-lived IMO. -Steve A fair analysis, but I think incomplete. Once again, the problem has more to do with the perception of new users and outsiders. I believe those of is in here, those of us who have frustrated and agonized over D over the last few years are going to be in a much better position of accepting the situation as it develops: we've grown with it, so our sympathies are well rooted -- we may very much enjoy having the option of using either of or both of two great libraries. I can easily agree that your analysis has some sense to it because of that. But, as I said before, the hardest part remains in finding a method to promote it as a "good thing" to everyone else who has no real emotional attatchment to the language, those who see learning a language as a synonymous with learning one "standard" library (because that seems to be the general history of programming languages). Maybe I'm wrong about this one (I hope I am wrong, and you are right), but I don't think it's wise to completely discredit the possibility of a problem in having two popular libraries at the core of D 2.0. If the libraries do go the Beta/VHS route... well that's just a mercy for D. Still trying to think positively, of course. :) -JJR
Re: Any chance to call Tango as Extended Standard Library
Sean Kelly: > This assumes that the easy approach is slow and the fast approach is > complex. I'd hope that we could find something that's both easy and > fast :-) I agree that certain times it's possible to have something that is both simple, safe, short and fast (but if that yield can be used for parallel iterations, then it may become slowish). But here there's another thing to consider: you may also want something quite flexible (see the complexity of Range). This is very difficult to do, that's why I have suggested two syntaxes, one simpler than opApply that requires you no brain to use it, plus the Range syntax developed so far (that may need small improvements but I doubt I'll ever be able to improve a lot, because Alex is good). Bye, bearophile
Re: Any chance to call Tango as Extended Standard Library
== Quote from bearophile (bearophileh...@lycos.com)'s article > Andrei Alexandrescu: > > I know. Its popularity is part of what makes it dangerous. It's to good > > programming what fast food is to food :o). > I think that's a false analogy: fast food kills you slowly, while experience > shows me that in many programs a significant (large) percentage of lines of code don't need to be a the top performance. > So a good thing to do in such parts is to use the most handy, easy to > remember, safer (as in anti-bug-prone), and short syntax/semantics you have. In the other small percentage of the code where performance is all important and/or you need full flexibility, you can tolerate something less easy to remember and harder to understand syntax/semantics (that you may also need to look into the docs if you don't know how to write). This assumes that the easy approach is slow and the fast approach is complex. I'd hope that we could find something that's both easy and fast :-) Sean
Re: Any chance to call Tango as Extended Standard Library
Andrei Alexandrescu:
> I know. Its popularity is part of what makes it dangerous. It's to good
> programming what fast food is to food :o).
I think that's a false analogy: fast food kills you slowly, while experience
shows me that in many programs a significant (large) percentage of lines of
code don't need to be a the top performance.
So a good thing to do in such parts is to use the most handy, easy to remember,
safer (as in anti-bug-prone), and short syntax/semantics you have. In the other
small percentage of the code where performance is all important and/or you need
full flexibility, you can tolerate something less easy to remember and harder
to understand syntax/semantics (that you may also need to look into the docs if
you don't know how to write).
This may lead to have two different syntaxes/solutions in the D2 language.
Duplication is generally bad. But if the first syntax/solution is simple enough
(like, simpler than the current opApply, that I have to look up each time
despite using it often), then the summed complexity of both solutions isn't
much bigger than the complexity of the second solution alone :-)
So I think having a syntax simpler than the opApply plus a full ranged syntax
can be acceptable. The simpler syntax may look for example more or less like
this (as you can see there is very little noise and very little to remember):
struct DoubleRange(int n) {
int opIter() {
for (int i; i < n; i++)
yield(i * 2);
yield(1000);
}
}
The following handy lazy iterable may even become syntactic sugar for the
struct I have just shown, as you can see even less noise, for a really common
programming pattern:
yield int doubleRange(int n) {
for (int i; i < n; i++)
yield(i * 2);
yield(1000);
}
Currently with my libs you have to write the following, that is less nice (and
it's not compiler-supported, so it's probably slower than necessary) (idea
adapted and modified from Witold Baryluk):
http://www.fantascienza.net/leonardo/so/dlibs/generators.html
struct DoubleRange(int n) {
void generator() {
for (int i; i < n; i++)
yield(i * 2);
yield(1000);
}
mixin Generator!(int);
}
Bye,
bearophile
Re: Any chance to call Tango as Extended Standard Library
Jason House wrote:
void iterateOverArray(T)(T[] arr){
foreach (i; 0..arr.length)
yield(arr[i]);
}
Coroutines are the slowest option, but the easiest to write. It takes 32
instructions or so to switch to or from a coroutine on x86. I'm not sure
how that translates in terms of memory usage, though. A delegate is
reasonably fast. A range struct's methods can be inlined (though opApply
could be, too, in some cases).
However, any collection library using polymorphism will have to use
polymorphic iterators. This means you probably won't get any benefit in
terms of speed from using ranges -- quite the opposite. But there are
benefits.
Re: Any chance to call Tango as Extended Standard Library
Mon, 19 Jan 2009 06:15:06 -0800, Andrei Alexandrescu wrote:
> Michel Fortin wrote:
>> Other possible things involves a rudimentary profiler (checking for the
>> elapsed time at each loop iteration), or a progress monitoring template
>> (notifying another thread of the progress of a particular task).
>>
>> foreach (task; progessUpdater(timeProfiler(listOfTasks)))
>> { ... }
>
> You can't compose iteration based on opApply. How would progessUpdater
> and timeProfiler look like? This example pretty much transforms your
> argument into mine :o).
I think "can't" is a bit strong a statement. Let's see:
With opApply:
class progressUpdater(Collection)
{
this(Collection c)
{
collection_ = c;
}
int opApply(int delegate(ref ElementType!(Collection)) dg)
{
composed_ = dg;
return collection_.opApply(&fancifier);
}
private:
int fancifier(ref ElementType!(Collection) el)
{
globalOnProgress();
return composed_(el);
}
Collection collection_;
int delegate(ref ElementType!(Collection)) composed_;
}
With ranges:
struct progressUpdater(Collection)
{
this(Collection c)
{
collection_ = c;
}
typeof(collection_.head) head()
{
return collection_.head;
}
void next()
{
globalOnProgress();
collection_.next();
}
bool empty()
{
return collection_.empty;
}
private Collection collection_;
}
Cannot see anything impossible with both.
Re: Any chance to call Tango as Extended Standard Library
aarti_pl wrote: > first - last > advance - retreat My preference: head - rhead next - rnext (or advance - radvance) The purpose of "retreat" and "toe" is to allow reverse iteration. "retreat" in not the opposite of "advance"/"next", it's the same operation applied to the other end of the range. So why not make this explicit by prefixing an 'r' to these reverse iteration functions? -- Rainer Deyke - rain...@eldwood.com
Re: Any chance to call Tango as Extended Standard Library
Andrei Alexandrescu pisze: John Reimer wrote: Hello Christopher, Walter Bright wrote: Yigal Chripun wrote: Walter Bright wrote: Lars Ivar Igesund wrote: toe() ?! tail() good, rear() not so good, toe() sucks. tail() is no good because it has a well-established meaning in programming of being everything but the first element of a list. I just didn't like rear(), as it is not normally thought of as the opposite of head(). What was the reason for the use of body parts in the first place? What's wrong with: a) begin, end b) start, finish c) initial, final d) first, last etc... There doesn't really need to be anything wrong with them. What's wrong with head/toe? It sounds stupid. I agree that its ugly. Although, be prepared to see it turn into just another feature that we're going to have to get used to. :) If there's widespread opinion that the current choice of names is unfortunate, now is the perfect time to fix that as the names haven't been put in heavy use. Things to keep in mind: * The operations next and retreat are not necessarily antonyms. I mean retreat does NOT undo what next does. So next and previous aren't quite desirable. * "head" will be used much more often than "toe". Most of the time, empty, head, and next will be used. These are the elements that support input ranges. "toe" and "retreat" are for bidirectional ranges. * The terms should be applicable equally well to generators (series, random numbers...), streams (files, sockets...), collections (lists, arrays...) and the such. * Short, one-word terms are preferred. Last but not least, keep in mind that these discussions could go on forever and that someone's best naming convention is another's worst. Happy hunting :o). Andrei first - last advance - retreat Above seems to me much more streamlined, than current choice. BR Marcin Kuszczak (aarti_pl)
Re: Any chance to call Tango as Extended Standard Library
Andrei Alexandrescu pisze: Steven Schveighoffer wrote: "Andrei Alexandrescu" wrote Steven Schveighoffer wrote: While we're on the subject of ditching, can we get rid of foreach_reverse? How hard is it for a range to just have a reverse property: foreach(element; myrange.reverse) Which simply reverses the order of traversal? That also would moot the toe/last/tail/etc. debate ;) I wish that debate went away. But eliminating toe and retreat would require requiring .reverse as a primitive for *all* ranges, which is wasteful and repetitive. Instead, a better design is to have ranges (those that can) offer toe and retreat primitives such that a generic function retro offers backward iteration for any range. In addition, certain algorithms (such as the one that reverses a range in place) need to manipulate the same range from two ends. Implementing them using .reverse and a second range would be more difficult. I didn't say you couldn't provide toe and retreat in Phobos' ranges (for the reverse-a-range function). Most likely such an algorithm is not using foreach and foreach_reverse, but using the functions directly. My point was, foreach_reverse is an eyesore and a hack, and there really is no need for it. And what a perfect time to get rid of it, since we are already changing how foreach works ;) I realize that this wouldn't really kill the toe debate for Phobos, but at least it would be a library decision, and not part of the compiler. Yah, that makes sense. I vote for foreach_reverse to go away, too. Andrei vote++ BR Marcin Kuszczak (aarti_pl)
Re: Any chance to call Tango as Extended Standard Library
== Quote from Jason House (jason.james.ho...@gmail.com)'s article
> Andrei Alexandrescu wrote:
> > Jason House wrote:
> >> Andrei Alexandrescu wrote:
> >>
> >>> Speed is a small part of the equation, in fact a perk only. Ranges
> >>> are composable; you can combine them to e.g. do parallel iteration
> >>> over two ranges. Ranges really open std.algorithm to all data
> >>> structures. I find opApply incredibly obtuse and fostering bad
> >>> design. I wish it goes away.
> >>
> >> I'd really hate to see opApply go away. I'm glad Walter says it's
> >> sticking around ;)
> >
> > I know. Its popularity is part of what makes it dangerous. It's to good
> > programming what fast food is to food :o).
> >
> >> opApply is really nice in how *simple* it is to write. I think it's
> >> possible to use druntime's fibers to convert an opApply
> >> implementation into a range implementation. It'd be an interesting
> >> challenge to write a templated struct that handles all of this. Once
> >> that is done, maybe someone could discuss using Fibers to implement
> >> opApply in D2. I suspect the code inside an opApply would only
> >> change a little bit and it'd allow iteration over multiple "ranges"
> >> at the same time.
> >
> > But that's making the mythical bear dance. Iterating over multiple
> > ranges is only one example. How do you feed one range to another range
> > with opApply?
> >
> > At the end of the day, if what you want is to iterate, you need to
> > define what the state of iteration is, how to make a step, and how to
> > get to the current element being iterated. That is a good design, not
> > opApply and fibers!
> >
> >
> > Andrei
> Are you saying that nobody should ever use coroutines? A coroutine version of
opApply keeps the state of iteration as part of the natural flow of making steps
and getting the current element being iterated. Let's look at various
implementation examples:
> current opApply style:
> int opApply(int delegate( ref T ) dg){
> int unknown;
> foreach(i; 0..length){
> unknown = dg(arr[i]);
> if (unknown != 0)
> return unknown;
> }
> return 0;
> }
> With coroutine:
> void iterateOverArray(T)(T[] arr){
> foreach (i; 0..arr.length)
> yield(arr[i]);
> }
> ... or maybe something more complex like the following is required?
> void iterateOverArray(T)(T[] arr){
> foreach (i; 0..arr.length){
> yield!("empty") = false;
> yield!("next") = arr[i];
> }
> yield!("empty") = true;
> }
> A range-based struct:
> struct arrayIterator(T){
> int _i;
> T[] _arr;
> this(T[] arr){
> arr = _arr;
> }
> T next(){
> return arr[i++];
> }
> bool empty{
> return i<_arr.length;
> }
> }
> Here are the line counts for the above implementations:
> current opApply style: 9
> coroutine with implied empty: 4
> coroutine with explicit empty: 7
> range-based: 13
> Which one would D users want to write? Personally, I want the coroutine with
implied empty. I could see having to explicitly state empty or at least specify
when it changes. If the above examples don't convince you that D should
consider
allowing alternate implementations to basic range structs, then I'll stop trying
to convince you.
Yeah, but we also want decent performance and even compared to opApply,
coroutines/fibers are slow as molasses in January at the North Pole during the
last Ice Age.
Re: Any chance to call Tango as Extended Standard Library
Andrei Alexandrescu wrote:
> Jason House wrote:
>> Andrei Alexandrescu wrote:
>>
>>> Speed is a small part of the equation, in fact a perk only. Ranges
>>> are composable; you can combine them to e.g. do parallel iteration
>>> over two ranges. Ranges really open std.algorithm to all data
>>> structures. I find opApply incredibly obtuse and fostering bad
>>> design. I wish it goes away.
>>
>> I'd really hate to see opApply go away. I'm glad Walter says it's
>> sticking around ;)
>
> I know. Its popularity is part of what makes it dangerous. It's to good
> programming what fast food is to food :o).
>
>> opApply is really nice in how *simple* it is to write. I think it's
>> possible to use druntime's fibers to convert an opApply
>> implementation into a range implementation. It'd be an interesting
>> challenge to write a templated struct that handles all of this. Once
>> that is done, maybe someone could discuss using Fibers to implement
>> opApply in D2. I suspect the code inside an opApply would only
>> change a little bit and it'd allow iteration over multiple "ranges"
>> at the same time.
>
> But that's making the mythical bear dance. Iterating over multiple
> ranges is only one example. How do you feed one range to another range
> with opApply?
>
> At the end of the day, if what you want is to iterate, you need to
> define what the state of iteration is, how to make a step, and how to
> get to the current element being iterated. That is a good design, not
> opApply and fibers!
>
>
> Andrei
Are you saying that nobody should ever use coroutines? A coroutine version of
opApply keeps the state of iteration as part of the natural flow of making
steps and getting the current element being iterated. Let's look at various
implementation examples:
current opApply style:
int opApply(int delegate( ref T ) dg){
int unknown;
foreach(i; 0..length){
unknown = dg(arr[i]);
if (unknown != 0)
return unknown;
}
return 0;
}
With coroutine:
void iterateOverArray(T)(T[] arr){
foreach (i; 0..arr.length)
yield(arr[i]);
}
... or maybe something more complex like the following is required?
void iterateOverArray(T)(T[] arr){
foreach (i; 0..arr.length){
yield!("empty") = false;
yield!("next") = arr[i];
}
yield!("empty") = true;
}
A range-based struct:
struct arrayIterator(T){
int _i;
T[] _arr;
this(T[] arr){
arr = _arr;
}
T next(){
return arr[i++];
}
bool empty{
return i<_arr.length;
}
}
Here are the line counts for the above implementations:
current opApply style: 9
coroutine with implied empty: 4
coroutine with explicit empty: 7
range-based: 13
Which one would D users want to write? Personally, I want the coroutine with
implied empty. I could see having to explicitly state empty or at least
specify when it changes. If the above examples don't convince you that D
should consider allowing alternate implementations to basic range structs, then
I'll stop trying to convince you.
Re: Any chance to call Tango as Extended Standard Library
== Quote from Michel Fortin (michel.for...@michelf.com)'s article > On 2009-01-18 10:21:55 -0500, Andrei Alexandrescu > 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 > .retreatmove 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. advance/retreat or next/prev. I use the latter in my own code, but perhaps an abbreviation isn't appropriate here. Sean
Re: Any chance to call Tango as Extended Standard Library
"Jason House" wrote > Walter Bright wrote: > >> Druntime is there, and it's up to the Tango team now. > > As I understand it, the biggest fear of the Tango team is to make an > official D2 version and then have to chase after a moving standard. If an > official port of Tango 0.99.7 was ported to work with dmd v2.023 how > willing would you be to ensure that the D2 Tango was functional prior to > new releases of dmd? I don't necessarily mean that you personally hack at > Tango D2 for every release with breaking changes but rather that you have > people lined up to compile and run unit tests, and fix problems prior to > each release? As far as I know, Walter has stated that he is willing to issue a quick fix release for easily fixed bugs that hurt Tango. This already happens with the D1 releases, and I'm sure he'd extend that courtesy for D2 releases once Tango D2 is relatively stable. I agree with Walter that the ball is fully in Tango's court. D2 not being stable is probably the largest reason that most of the Tango devs aren't yet interested, but it doesn't stop some of us from trying :) Probably the largest hurdle right now is const-ifying all of Tango. Most of the time, this doesn't just imply slapping a const or immutable label on something, but really rethinking how a particular module is implemented to cater to const properly. Thankfully, however, const is now a stable target. Once pure/shared/unshared gets introduced, it will probably require more effort, but probably not as much as with const. > If the answer to that is yes, I'd be happy to sign up as a tester/fixer. > I can guarantee that I won't be able to do a large number of fixes before > a release, but would be able to do some. For most releases, that may be > enough. For big breaking changes, we'd need several tester/fixer people. > I also can't do a D2 + druntime port. I think there's already a > pre-druntime port of Tango to D2. I doubt I could do that job, and won't > sign up for it. I also won't sign up for porting new Tango functionality > to D2 either. > > Even with all of these restrictions, I believe that this could work for > the next year or two while D2 solidifies its design. I'd absolutely love > to see this, which is why I'm willing to help maintain it. Maybe there > will be other inspired individuals who would do the initial Tango D2 port > and others who may periodically update D2 Tango to match the latest and > greatest Tango D1 release. It's already being worked on, albeit slowly... Need more free time :) Any help is appreciated. My motivation for doing the port is to ensure D2's design is tested fully, as I believe many of the features aren't completely tested with Phobos alone. I've already found several D2 bugs just by porting some of Tango. My biggest fear is that D2 is released with some design decision that makes Tango impossible to port. -Steve
Re: Any chance to call Tango as Extended Standard Library
Jason House wrote: Andrei Alexandrescu wrote: Speed is a small part of the equation, in fact a perk only. Ranges are composable; you can combine them to e.g. do parallel iteration over two ranges. Ranges really open std.algorithm to all data structures. I find opApply incredibly obtuse and fostering bad design. I wish it goes away. I'd really hate to see opApply go away. I'm glad Walter says it's sticking around ;) I know. Its popularity is part of what makes it dangerous. It's to good programming what fast food is to food :o). opApply is really nice in how *simple* it is to write. I think it's possible to use druntime's fibers to convert an opApply implementation into a range implementation. It'd be an interesting challenge to write a templated struct that handles all of this. Once that is done, maybe someone could discuss using Fibers to implement opApply in D2. I suspect the code inside an opApply would only change a little bit and it'd allow iteration over multiple "ranges" at the same time. But that's making the mythical bear dance. Iterating over multiple ranges is only one example. How do you feed one range to another range with opApply? At the end of the day, if what you want is to iterate, you need to define what the state of iteration is, how to make a step, and how to get to the current element being iterated. That is a good design, not opApply and fibers! Andrei
Re: Any chance to call Tango as Extended Standard Library
Andrei Alexandrescu wrote: > Speed is a small part of the equation, in fact a perk only. Ranges are > composable; you can combine them to e.g. do parallel iteration over two > ranges. Ranges really open std.algorithm to all data structures. I find > opApply incredibly obtuse and fostering bad design. I wish it goes away. I'd really hate to see opApply go away. I'm glad Walter says it's sticking around ;) opApply is really nice in how *simple* it is to write. I think it's possible to use druntime's fibers to convert an opApply implementation into a range implementation. It'd be an interesting challenge to write a templated struct that handles all of this. Once that is done, maybe someone could discuss using Fibers to implement opApply in D2. I suspect the code inside an opApply would only change a little bit and it'd allow iteration over multiple "ranges" at the same time.
Re: Any chance to call Tango as Extended Standard Library
Walter Bright wrote: > Druntime is there, and it's up to the Tango team now. As I understand it, the biggest fear of the Tango team is to make an official D2 version and then have to chase after a moving standard. If an official port of Tango 0.99.7 was ported to work with dmd v2.023 how willing would you be to ensure that the D2 Tango was functional prior to new releases of dmd? I don't necessarily mean that you personally hack at Tango D2 for every release with breaking changes but rather that you have people lined up to compile and run unit tests, and fix problems prior to each release? If the answer to that is yes, I'd be happy to sign up as a tester/fixer. I can guarantee that I won't be able to do a large number of fixes before a release, but would be able to do some. For most releases, that may be enough. For big breaking changes, we'd need several tester/fixer people. I also can't do a D2 + druntime port. I think there's already a pre-druntime port of Tango to D2. I doubt I could do that job, and won't sign up for it. I also won't sign up for porting new Tango functionality to D2 either. Even with all of these restrictions, I believe that this could work for the next year or two while D2 solidifies its design. I'd absolutely love to see this, which is why I'm willing to help maintain it. Maybe there will be other inspired individuals who would do the initial Tango D2 port and others who may periodically update D2 Tango to match the latest and greatest Tango D1 release.
Re: Any chance to call Tango as Extended Standard Library
Steven Schveighoffer wrote: "Andrei Alexandrescu" wrote Steven Schveighoffer wrote: While we're on the subject of ditching, can we get rid of foreach_reverse? How hard is it for a range to just have a reverse property: foreach(element; myrange.reverse) Which simply reverses the order of traversal? That also would moot the toe/last/tail/etc. debate ;) I wish that debate went away. But eliminating toe and retreat would require requiring .reverse as a primitive for *all* ranges, which is wasteful and repetitive. Instead, a better design is to have ranges (those that can) offer toe and retreat primitives such that a generic function retro offers backward iteration for any range. In addition, certain algorithms (such as the one that reverses a range in place) need to manipulate the same range from two ends. Implementing them using .reverse and a second range would be more difficult. I didn't say you couldn't provide toe and retreat in Phobos' ranges (for the reverse-a-range function). Most likely such an algorithm is not using foreach and foreach_reverse, but using the functions directly. My point was, foreach_reverse is an eyesore and a hack, and there really is no need for it. And what a perfect time to get rid of it, since we are already changing how foreach works ;) I realize that this wouldn't really kill the toe debate for Phobos, but at least it would be a library decision, and not part of the compiler. Yah, that makes sense. I vote for foreach_reverse to go away, too. Andrei
Re: Any chance to call Tango as Extended Standard Library
"Andrei Alexandrescu" wrote > Steven Schveighoffer wrote: >> While we're on the subject of ditching, can we get rid of >> foreach_reverse? How hard is it for a range to just have a reverse >> property: >> >> foreach(element; myrange.reverse) >> >> Which simply reverses the order of traversal? That also would moot the >> toe/last/tail/etc. debate ;) > > I wish that debate went away. But eliminating toe and retreat would > require requiring .reverse as a primitive for *all* ranges, which is > wasteful and repetitive. Instead, a better design is to have ranges (those > that can) offer toe and retreat primitives such that a generic function > retro offers backward iteration for any range. In addition, certain > algorithms (such as the one that reverses a range in place) need to > manipulate the same range from two ends. Implementing them using .reverse > and a second range would be more difficult. I didn't say you couldn't provide toe and retreat in Phobos' ranges (for the reverse-a-range function). Most likely such an algorithm is not using foreach and foreach_reverse, but using the functions directly. My point was, foreach_reverse is an eyesore and a hack, and there really is no need for it. And what a perfect time to get rid of it, since we are already changing how foreach works ;) I realize that this wouldn't really kill the toe debate for Phobos, but at least it would be a library decision, and not part of the compiler. -Steve
Re: Any chance to call Tango as Extended Standard Library
Steven Schveighoffer wrote: "Piotrek" wrote Hello! It's just an idea. After reading about issues on disallowing DWT to stay in standardization area (Anomaly on Wiki4D GuiLibraries page) some question appeared in my mind. For propaganda sake isn't it better to not make such a big division between phobos and tango in the module naming? Logically: phobos -> std tango -> stdex (not tango -> tango) Let's not forget the licensing issues. Tango is incompatible with some developers license wise, as you must include attribution for Tango in any derivative works (i.e. compiled binaries). Phobos has a less restrictive opt-in policy. I think Walter intends to keep it that way, at least for DMD. Note that other compilers are free to use Tango or their own standard library, the D spec is pretty free from library references. Yah. This also creates some asymmetry, as e.g. Walter avoids looking at Tango whereas Phobos is out in the clear. Given that I work on Phobos too and know next to nothing about licensing issues, I myself defaulted to not looking at Tango (I did look cursory a couple of years ago, before being involved with Phobos.) I also don't think this is a bad thing. One of two things will happen. Either one library totally dominates the other, and eventually everyone starts using the more popular one (the Beta/VHS route), or both libraries flourish, and due to the common runtime, can be used concurrently in projects (the KDE/GNOME route). Either way, I don't see the current rift between Tango/Phobos being a major detriment to D. It will be short-lived IMO. Nicely put. I believe the same. Andrei
Re: Any chance to call Tango as Extended Standard Library
Steven Schveighoffer wrote:
"Andrei Alexandrescu" wrote
Bill Baxter wrote:
On Mon, Jan 19, 2009 at 9:16 AM, Andrei Alexandrescu
wrote:
Unless it's a class you mean?
Yah, ranges are meant to have value semantics. If you have a class
container
exposing ranges, define the range separately from the container itself:
MyIterable collection;
foreach (element; collection.all) {}
foreach (element; collection.all) {}
Add .opRange so that's not necessary? Or allow opApply to return a
range?
Otherwise it looks like a step backwards.
Why is it a step backwards? A given container may define a number of
ranges. Arrays are deceivingly simple because they have one obvious way of
iteration, but even for them you'd have to write:
int[] a;
foreach (element; a.retro) { ... }
I have to side with the others on this. foreach(element; collection) is so
damned intuitive ("for each element in a collection"), it should at least
try to call a default range function first, before trying to use collection
as a range. I'm for having opRange, and ditching opApply. I don't really
see the need for opApply (and I used a lot of forwarding opApply calls in
dcollections, so I'll probably have to rewrite that now!). You could also
write cool things like (for instance in a string-indexed collection):
foreach(element; collection["a".."m"])
instead of
foreach(element; collection["a".."m"].all)
Ok, I understand.
While we're on the subject of ditching, can we get rid of foreach_reverse?
How hard is it for a range to just have a reverse property:
foreach(element; myrange.reverse)
Which simply reverses the order of traversal? That also would moot the
toe/last/tail/etc. debate ;)
I wish that debate went away. But eliminating toe and retreat would
require requiring .reverse as a primitive for *all* ranges, which is
wasteful and repetitive. Instead, a better design is to have ranges
(those that can) offer toe and retreat primitives such that a generic
function retro offers backward iteration for any range. In addition,
certain algorithms (such as the one that reverses a range in place) need
to manipulate the same range from two ends. Implementing them using
.reverse and a second range would be more difficult.
Andrei
Re: Any chance to call Tango as Extended Standard Library
"Piotrek" wrote > Hello! > > It's just an idea. After reading about issues on disallowing DWT to stay > in standardization area (Anomaly on Wiki4D GuiLibraries page) some > question appeared in my mind. For propaganda sake isn't it better to not > make such a big division between phobos and tango in the module naming? > Logically: > > phobos -> std > tango -> stdex (not tango -> tango) Let's not forget the licensing issues. Tango is incompatible with some developers license wise, as you must include attribution for Tango in any derivative works (i.e. compiled binaries). Phobos has a less restrictive opt-in policy. I think Walter intends to keep it that way, at least for DMD. Note that other compilers are free to use Tango or their own standard library, the D spec is pretty free from library references. With regards to Tango for D2. It is going to happen. It may not be tomorrow, but it will probably be done this year. To answer some questions throughout this discussion, it will look similar to Tango/D1, but will utilize many of the features of D2, as well as obey the requirements. For example, it's not simply going to cast away const to keep the implementation closer to D1. So it will look different than Tango/D1 and most likely, will not be one code base. Which means, people will have to maintain both, which is no small feat. But it can (and will) be done. I like D2 too much to not do it :) The Tango D2 branch currently in SVN compiles and runs on Linux DMD 2.019. We have basic functionality for many of the examples, but not all unit tests pass. However, it should be usable to test simple code. So far, we have ported completely tango.core and tango.util.log. We have yet to incorporate druntime, as I didn't want to tackle issues that might be in druntime as well as porting issues. I think I will try to upgrade to 2.023, as it seems druntime/compiler interaction is getting a lot more stable, and then continue porting. I don't see Tango and Phobos becoming more like one or the other, but as others have said, there are definite sections of code that can be used from both without interference. I/O is not one of them, and I don't see that changing. But due to the open source nature, you can port or re-implement features of one library into the other, so while you may be choosing between two different styles, you shouldn't have to choose one or the other for functionality. I also don't think this is a bad thing. One of two things will happen. Either one library totally dominates the other, and eventually everyone starts using the more popular one (the Beta/VHS route), or both libraries flourish, and due to the common runtime, can be used concurrently in projects (the KDE/GNOME route). Either way, I don't see the current rift between Tango/Phobos being a major detriment to D. It will be short-lived IMO. -Steve
Re: Any chance to call Tango as Extended Standard Library
dsimcha wrote: == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article Depends on how you define "fancy". If "fancy" includes "composable", opApply isn't that. Andrei Can you give an example of composable ranges, because I'm not sure exactly what you mean or how it works. Given two ranges, iterate both in lockstep. Andrei
Re: Any chance to call Tango as Extended Standard Library
Daniel Keep wrote:
Don wrote:
[snip]
And in fact, a Tango2 floor plan would be a good idea, too. For example,
now that D2 supports foreach ranges, Tango containers will almost
certainly want to support them.
For reference, from tango.util.collection.model.Iterator:
public interface Iterator(V)
{
public bool more();
public V get();
int opApply (int delegate (inout V value) dg);
}
Basically, Tango's iterators use more (negation of empty,) and get
(which is next and head combined.)
This brings up a request I have for Andrei: please ensure there is an
actual interface for ranges (preferably enforced.) Compile-time duck
typing [1] is awesome, but sometimes you need run-time polymorphism.
There is a persistent misunderstanding about the two. They're not
competing. Duck typing as used in foreach and ranges does not preclude
definition and use of explicit interfaces and dynamic polymorphism.
Andrei
Re: Any chance to call Tango as Extended Standard Library
Steven Schveighoffer wrote: "Andrei Alexandrescu" wrote It's been there for a while now (since 25 Nov 2008). http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement Strange that I never noticed that. I remember when 2.022 came out, I did not see it there, but I guess I could have overlooked it. It definitely was not there when 2.021 came out (I remember many people asking for docs on it, including myself). One question, it mentions that you must define all 5 properties. In the case where you are only going to use foreach (and not foreach_reverse) on a struct, is it still required that you implement toe and retreat? If not, then that probably should be mentioned in the docs. Yah, only the minimum is required. Walter should change the docs :o). Andrei
Re: Any chance to call Tango as Extended Standard Library
"Andrei Alexandrescu" wrote
> Bill Baxter wrote:
>> On Mon, Jan 19, 2009 at 9:16 AM, Andrei Alexandrescu
>> wrote:
>>
Unless it's a class you mean?
>>> Yah, ranges are meant to have value semantics. If you have a class
>>> container
>>> exposing ranges, define the range separately from the container itself:
>>>
>>> MyIterable collection;
>>> foreach (element; collection.all) {}
>>> foreach (element; collection.all) {}
>>
>> Add .opRange so that's not necessary? Or allow opApply to return a
>> range?
>> Otherwise it looks like a step backwards.
>
> Why is it a step backwards? A given container may define a number of
> ranges. Arrays are deceivingly simple because they have one obvious way of
> iteration, but even for them you'd have to write:
>
> int[] a;
> foreach (element; a.retro) { ... }
I have to side with the others on this. foreach(element; collection) is so
damned intuitive ("for each element in a collection"), it should at least
try to call a default range function first, before trying to use collection
as a range. I'm for having opRange, and ditching opApply. I don't really
see the need for opApply (and I used a lot of forwarding opApply calls in
dcollections, so I'll probably have to rewrite that now!). You could also
write cool things like (for instance in a string-indexed collection):
foreach(element; collection["a".."m"])
instead of
foreach(element; collection["a".."m"].all)
While we're on the subject of ditching, can we get rid of foreach_reverse?
How hard is it for a range to just have a reverse property:
foreach(element; myrange.reverse)
Which simply reverses the order of traversal? That also would moot the
toe/last/tail/etc. debate ;)
-Steve
Re: Any chance to call Tango as Extended Standard Library
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article > Depends on how you define "fancy". If "fancy" includes "composable", > opApply isn't that. > Andrei Can you give an example of composable ranges, because I'm not sure exactly what you mean or how it works.
Re: Any chance to call Tango as Extended Standard Library
Don wrote:
> [snip]
>
> And in fact, a Tango2 floor plan would be a good idea, too. For example,
> now that D2 supports foreach ranges, Tango containers will almost
> certainly want to support them.
For reference, from tango.util.collection.model.Iterator:
public interface Iterator(V)
{
public bool more();
public V get();
int opApply (int delegate (inout V value) dg);
}
Basically, Tango's iterators use more (negation of empty,) and get
(which is next and head combined.)
This brings up a request I have for Andrei: please ensure there is an
actual interface for ranges (preferably enforced.) Compile-time duck
typing [1] is awesome, but sometimes you need run-time polymorphism.
-- Daniel
[1] There's a funny case of this falling to pieces in C#; they
introduced templates in C# 2.0, I believe. However, to do anything
moderately useful, you had to use interfaces to tell the compiler what
was acceptable to pass.
Of course, you can't have operator overloads in interfaces, which meant
it's IMPOSSIBLE to do any form of arithmetic in templates in C#. Whoops.
Re: Any chance to call Tango as Extended Standard Library
"Andrei Alexandrescu" wrote > It's been there for a while now (since 25 Nov 2008). > > http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement Strange that I never noticed that. I remember when 2.022 came out, I did not see it there, but I guess I could have overlooked it. It definitely was not there when 2.021 came out (I remember many people asking for docs on it, including myself). One question, it mentions that you must define all 5 properties. In the case where you are only going to use foreach (and not foreach_reverse) on a struct, is it still required that you implement toe and retreat? If not, then that probably should be mentioned in the docs. -Steve
Re: Any chance to call Tango as Extended Standard Library
"Jason House" wrote > Andrei Alexandrescu wrote: > >> I'd be curious to find out more about a runtime queryable struct >> interface. How would it work? What idioms would it enable? > > I don't know what Lars is thinking of, but I think of struct interfaces as > a non-polymorphic / compile-time inheritance. AKA, you can have a struct > implement it, but you can't cast it to a base struct/interface. Outside > of defining the struct, I'd expect it to only be usable in templates and > is-expressions I would expect a struct interface to be castable to the interface. Otherwise, you get no benefit from having it. You can already use compile-time interfaces with concepts and templates. The issue then becomes to make a struct interface act the same as a class interface. Unfortunately, a class interface value only contains a vtable pointer (I think), which contains the offset to get to the actual class pointer. If the class pointer was passed with the interface, this would be much easier, but might be slower when doing class interfaces (passing 2 pointers instead of 1). You could put an interface vtable pointer at the beginning of a struct, which then makes every struct carry that extra baggage. And then a virtual call is required, but would allow much more dynamic behavior. You could build a temporary interface "structure" which does the thunk to point to the real struct, since you don't have to deal with possible inheritance, to avoid putting a vtable in the struct. There are probably other ways. In any case, having struct interfaces probably is not the best method for ranges, where you would be doing a virtual call over and over again. But it would be hugely beneficial for things like non-templated I/O, or serialization. One problem to consider is that it is much easier for a struct to escape it's scope, so you may have to require a scope parameter to pass a struct as an interface. -Steve
Re: Any chance to call Tango as Extended Standard Library
John Reimer wrote: Hello Christopher, Walter Bright wrote: Yigal Chripun wrote: Walter Bright wrote: Lars Ivar Igesund wrote: toe() ?! tail() good, rear() not so good, toe() sucks. tail() is no good because it has a well-established meaning in programming of being everything but the first element of a list. I just didn't like rear(), as it is not normally thought of as the opposite of head(). What was the reason for the use of body parts in the first place? What's wrong with: a) begin, end b) start, finish c) initial, final d) first, last etc... There doesn't really need to be anything wrong with them. What's wrong with head/toe? It sounds stupid. I agree that its ugly. Although, be prepared to see it turn into just another feature that we're going to have to get used to. :) If there's widespread opinion that the current choice of names is unfortunate, now is the perfect time to fix that as the names haven't been put in heavy use. Things to keep in mind: * The operations next and retreat are not necessarily antonyms. I mean retreat does NOT undo what next does. So next and previous aren't quite desirable. * "head" will be used much more often than "toe". Most of the time, empty, head, and next will be used. These are the elements that support input ranges. "toe" and "retreat" are for bidirectional ranges. * The terms should be applicable equally well to generators (series, random numbers...), streams (files, sockets...), collections (lists, arrays...) and the such. * Short, one-word terms are preferred. Last but not least, keep in mind that these discussions could go on forever and that someone's best naming convention is another's worst. Happy hunting :o). Andrei
Re: Any chance to call Tango as Extended Standard Library
John Reimer wrote: Hello Don, dsimcha wrote: == Quote from Don (nos...@nospam.com)'s article I completely disagree. I think the two libraries is a disaster. I can see that so many people have been exposed to a lifetime of propaganda that "competition is a good thing", but it's just propaganda. Competition inevitably means wasted effort, and it's obvious in D. On a purely philosopical note, yes, cooperation is better than competition *if* there's enough of a consensus among the parties involved as to how things should be run. However, this is a *BIG* if. The problem with ideologies that are strongly against competition is that this is very seldom true in the real world. (Phobos vs. Tango is one example) In these cases, where there is simply no consensus, the only realistic alternative to competition is to have winners and losers picked in a dictatorial fashion by some form of authority. Yes, this authority could be selected democratically by voting, but tyranny of the majority is still tyranny. In the case of Phobos vs. Tango, Walter could hypothetically just try his absolute hardest to kill off Tango, in the name of preventing competition, but I'm sure noone wants that. Therefore, where no true consensus exists or ever realistically will exist, competition is often a lesser evil than having a winner arbitrarily picked by some form of authority. I'm not convinced that there really is a major idealogical difference between Phobos and Tango. At the time Tango was formed, Phobos was virtually stagnant. It was a random accretion of contributions by various authors from various points in D's history. All changes to Phobos were manually made by Walter, who had too much on his plate already. _Nobody_ thought that that situation was ideal. Tango1 is in direct competition with Phobos1, but Phobos1 is frozen. Phobos2 is _not_ the same as Phobos1, and breaks compatibility with it in many serious ways. And Phobos1 and 2 are likely to diverge even more with time. There are in fact many similarities between Phobos2 and Tango1. Now we're getting some genuinely different approaches between Phobos2 and Tango1, but they seem to be driven as much by the new capabilities in D2, as by philosophical differences. So I see two critical questions: (1) to what extent will Tango2 embrace D2 features, at the expense of backward compatibility with Tango1? (The more it embraces D2, the closer it will become to Phobos2); and (2) are both libraries prepared to eliminate the many superficial differences between them? Can we merge Tango2 and Phobos2, given that neither of them completely exist yet? I agree that these are the critical questions, and we will need to see them answered eventually. The question is "when?" I suppose, the Tango people probably can't answer that until they see a stable D 2.0 and a complete Phobos 2. On the other hand, perhaps its a very good time for Tango guys to be introduced to the Phobos 2 floor plan so that both sides can see if their goals can merge somehow. -JJR And in fact, a Tango2 floor plan would be a good idea, too. For example, now that D2 supports foreach ranges, Tango containers will almost certainly want to support them.
Re: Any chance to call Tango as Extended Standard Library
Hello Christopher, Walter Bright wrote: Yigal Chripun wrote: Walter Bright wrote: Lars Ivar Igesund wrote: toe() ?! tail() good, rear() not so good, toe() sucks. tail() is no good because it has a well-established meaning in programming of being everything but the first element of a list. I just didn't like rear(), as it is not normally thought of as the opposite of head(). What was the reason for the use of body parts in the first place? What's wrong with: a) begin, end b) start, finish c) initial, final d) first, last etc... There doesn't really need to be anything wrong with them. What's wrong with head/toe? It sounds stupid. I agree that its ugly. Although, be prepared to see it turn into just another feature that we're going to have to get used to. :) -JJR
Re: Any chance to call Tango as Extended Standard Library
Hello Don, dsimcha wrote: == Quote from Don (nos...@nospam.com)'s article I completely disagree. I think the two libraries is a disaster. I can see that so many people have been exposed to a lifetime of propaganda that "competition is a good thing", but it's just propaganda. Competition inevitably means wasted effort, and it's obvious in D. On a purely philosopical note, yes, cooperation is better than competition *if* there's enough of a consensus among the parties involved as to how things should be run. However, this is a *BIG* if. The problem with ideologies that are strongly against competition is that this is very seldom true in the real world. (Phobos vs. Tango is one example) In these cases, where there is simply no consensus, the only realistic alternative to competition is to have winners and losers picked in a dictatorial fashion by some form of authority. Yes, this authority could be selected democratically by voting, but tyranny of the majority is still tyranny. In the case of Phobos vs. Tango, Walter could hypothetically just try his absolute hardest to kill off Tango, in the name of preventing competition, but I'm sure noone wants that. Therefore, where no true consensus exists or ever realistically will exist, competition is often a lesser evil than having a winner arbitrarily picked by some form of authority. I'm not convinced that there really is a major idealogical difference between Phobos and Tango. At the time Tango was formed, Phobos was virtually stagnant. It was a random accretion of contributions by various authors from various points in D's history. All changes to Phobos were manually made by Walter, who had too much on his plate already. _Nobody_ thought that that situation was ideal. Tango1 is in direct competition with Phobos1, but Phobos1 is frozen. Phobos2 is _not_ the same as Phobos1, and breaks compatibility with it in many serious ways. And Phobos1 and 2 are likely to diverge even more with time. There are in fact many similarities between Phobos2 and Tango1. Now we're getting some genuinely different approaches between Phobos2 and Tango1, but they seem to be driven as much by the new capabilities in D2, as by philosophical differences. So I see two critical questions: (1) to what extent will Tango2 embrace D2 features, at the expense of backward compatibility with Tango1? (The more it embraces D2, the closer it will become to Phobos2); and (2) are both libraries prepared to eliminate the many superficial differences between them? Can we merge Tango2 and Phobos2, given that neither of them completely exist yet? I agree that these are the critical questions, and we will need to see them answered eventually. The question is "when?" I suppose, the Tango people probably can't answer that until they see a stable D 2.0 and a complete Phobos 2. On the other hand, perhaps its a very good time for Tango guys to be introduced to the Phobos 2 floor plan so that both sides can see if their goals can merge somehow. -JJR
Re: Any chance to call Tango as Extended Standard Library
Michel Fortin wrote:
On 2009-01-18 22:00:17 -0500, Andrei Alexandrescu
said:
dsimcha wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
dsimcha wrote:
One point of clarification: opApply isn't going to be deprecated
anytime soon, is
it? It seems like ranges still have a bunch of rough edges, and
although I like
the idea in principle, I'm only willing to convert to ranges if I
can define
iterable objects with the same level of syntactic sugar as opApply
gives me. For
simple cases this is already true and I have begun converting some
stuff.
However, for more complicated cases, opApply is still a lot more
flexible.
opApply isn't going away. For one thing, it works very well with
recursive data structures.
So besides performance, what advantages does using ranges instead of
opApply for
iteration over structs/classes offer? According to some testing that
I just
finished on the hash table implementation I was talking about earlier
today, the
penalty for using opApply is small enough that, if using ranges
requires a bunch
of extra bookkeeping overhead that opApply doesn't, then opApply can
reasonably be
faster.
Speed is a small part of the equation, in fact a perk only. Ranges are
composable; you can combine them to e.g. do parallel iteration over
two ranges. Ranges really open std.algorithm to all data structures. I
find opApply incredibly obtuse and fostering bad design. I wish it
goes away.
Andrei
But if it goes away, that'd prevent a lot of cool things that could be
done with foreach. You could create a template that automatically
distributes iterations to various threads with very little code
(assuming the loop delegate is pure):
foreach (i; paralelize(myArray))
doSomethingComplicated();
All the complexity would lay in the opApply. You can't do this with ranges.
Parallelization crossed my mind too, although in the context of finding
files in subdirectories recursively. Using foreach for such stuff looks
cute, maybe too cute. Let's not forget that there is always the option
of calling a higher-order function:
distribute(myArray, &doSomethingComplicated);
Other possible things involves a rudimentary profiler (checking for the
elapsed time at each loop iteration), or a progress monitoring template
(notifying another thread of the progress of a particular task).
foreach (task; progessUpdater(timeProfiler(listOfTasks)))
{ ... }
You can't compose iteration based on opApply. How would progessUpdater
and timeProfiler look like? This example pretty much transforms your
argument into mine :o).
For basic data manipulation algorithms, ranges are better. But for more
fancy stuff, opApply still rules.
Depends on how you define "fancy". If "fancy" includes "composable",
opApply isn't that.
Andrei
Re: Any chance to call Tango as Extended Standard Library
Mon, 19 Jan 2009 09:47:14 +0900, Bill Baxter wrote:
> On Mon, Jan 19, 2009 at 9:16 AM, Andrei Alexandrescu
> wrote:
>
>>> Unless it's a class you mean?
>>
>> Yah, ranges are meant to have value semantics. If you have a class container
>> exposing ranges, define the range separately from the container itself:
>>
>> MyIterable collection;
>> foreach (element; collection.all) {}
>> foreach (element; collection.all) {}
>
> Add .opRange so that's not necessary? Or allow opApply to return a range?
> Otherwise it looks like a step backwards.
I already proposed that foreach should first try collection.opSlice()
and work with that if successful, otherwise resort to iterating over the
collection itself. You would probably implement opSlice anyway so this
solution comes at little cost.
Re: Any chance to call Tango as Extended Standard Library
On 2009-01-18 22:00:17 -0500, Andrei Alexandrescu
said:
dsimcha wrote:
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
dsimcha wrote:
One point of clarification: opApply isn't going to be deprecated
anytime soon, is
it? It seems like ranges still have a bunch of rough edges, and
although I like
the idea in principle, I'm only willing to convert to ranges if I can define
iterable objects with the same level of syntactic sugar as opApply
gives me. For
simple cases this is already true and I have begun converting some stuff.
However, for more complicated cases, opApply is still a lot more flexible.
opApply isn't going away. For one thing, it works very well with
recursive data structures.
So besides performance, what advantages does using ranges instead of
opApply for
iteration over structs/classes offer? According to some testing that I just
finished on the hash table implementation I was talking about earlier
today, the
penalty for using opApply is small enough that, if using ranges
requires a bunch
of extra bookkeeping overhead that opApply doesn't, then opApply can
reasonably be
faster.
Speed is a small part of the equation, in fact a perk only. Ranges are
composable; you can combine them to e.g. do parallel iteration over two
ranges. Ranges really open std.algorithm to all data structures. I find
opApply incredibly obtuse and fostering bad design. I wish it goes away.
Andrei
But if it goes away, that'd prevent a lot of cool things that could be
done with foreach. You could create a template that automatically
distributes iterations to various threads with very little code
(assuming the loop delegate is pure):
foreach (i; paralelize(myArray))
doSomethingComplicated();
All the complexity would lay in the opApply. You can't do this with ranges.
Other possible things involves a rudimentary profiler (checking for the
elapsed time at each loop iteration), or a progress monitoring template
(notifying another thread of the progress of a particular task).
foreach (task; progessUpdater(timeProfiler(listOfTasks)))
{ ... }
For basic data manipulation algorithms, ranges are better. But for more
fancy stuff, opApply still rules.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: Any chance to call Tango as Extended Standard Library
dsimcha wrote: == Quote from Don (nos...@nospam.com)'s article I completely disagree. I think the two libraries is a disaster. I can see that so many people have been exposed to a lifetime of propaganda that "competition is a good thing", but it's just propaganda. Competition inevitably means wasted effort, and it's obvious in D. On a purely philosopical note, yes, cooperation is better than competition *if* there's enough of a consensus among the parties involved as to how things should be run. However, this is a *BIG* if. The problem with ideologies that are strongly against competition is that this is very seldom true in the real world. (Phobos vs. Tango is one example) In these cases, where there is simply no consensus, the only realistic alternative to competition is to have winners and losers picked in a dictatorial fashion by some form of authority. Yes, this authority could be selected democratically by voting, but tyranny of the majority is still tyranny. In the case of Phobos vs. Tango, Walter could hypothetically just try his absolute hardest to kill off Tango, in the name of preventing competition, but I'm sure noone wants that. Therefore, where no true consensus exists or ever realistically will exist, competition is often a lesser evil than having a winner arbitrarily picked by some form of authority. I'm not convinced that there really is a major idealogical difference between Phobos and Tango. At the time Tango was formed, Phobos was virtually stagnant. It was a random accretion of contributions by various authors from various points in D's history. All changes to Phobos were manually made by Walter, who had too much on his plate already. _Nobody_ thought that that situation was ideal. Tango1 is in direct competition with Phobos1, but Phobos1 is frozen. Phobos2 is _not_ the same as Phobos1, and breaks compatibility with it in many serious ways. And Phobos1 and 2 are likely to diverge even more with time. There are in fact many similarities between Phobos2 and Tango1. Now we're getting some genuinely different approaches between Phobos2 and Tango1, but they seem to be driven as much by the new capabilities in D2, as by philosophical differences. So I see two critical questions: (1) to what extent will Tango2 embrace D2 features, at the expense of backward compatibility with Tango1? (The more it embraces D2, the closer it will become to Phobos2); and (2) are both libraries prepared to eliminate the many superficial differences between them? Can we merge Tango2 and Phobos2, given that neither of them completely exist yet?
Re: Any chance to call Tango as Extended Standard Library
Alexander Pánek wrote: Stewart Gordon wrote: Alexander Pánek wrote: Stewart Gordon wrote: D already has ONE standard library. It's called Phobos. *yawn* Don’t you get tired of this? I do get tired of the misunderstanding of what Tango is that seems to have arisen from the misterminology. It didn’t arise from misterminology, but people who do call it their (de-facto, but nonetheless) standard D library. You might not accept, respect or acknowledge this in any way, but then again you seem to be all into semantics. “A standard library for a programming language is the library that is conventionally made available in every implementation of that language. In some cases, the library is described directly in the programming language specification; in other cases, the contents of the standard library are determined by more informal social practices in the programming community.” Source: http://en.wikipedia.org/wiki/Standard_library I think Tango meets every but the first (conventional) “rule”. So there might have been a misunderstanding I do get tired of on your side.
Re: Any chance to call Tango as Extended Standard Library
Stewart Gordon wrote: Alexander Pánek wrote: Stewart Gordon wrote: D already has ONE standard library. It's called Phobos. *yawn* Don’t you get tired of this? I do get tired of the misunderstanding of what Tango is that seems to have arisen from the misterminology. It didn’t arise from misterminology, but people who do call it their (de-facto, but nonetheless) standard D library. You might not accept, respect or acknowledge this in any way, but then again you seem to be all into semantics. “A standard library for a programming language is the library that is conventionally made available in every implementation of that language. In some cases, the library is described directly in the programming language specification; in other cases, the contents of the standard library are determined by more informal social practices in the programming community.” I think Tango meets every but the first (conventional) “rule”. So there might have been a misunderstanding I do get tired of on your side. Kind regards, Alex
