On 20 November 2011 05:02, dsimcha <[email protected]> wrote: > Now that we've got a lot of contributors to Phobos and many projects in > the works, I decided to start a thread to help us make a rough plan for > Phobos's short-to-medium term development. There are three goals here: > > 1. Determine what's next in the review queue after std.csv (voting on > std.csv ends tonight, so **please vote**). > > 2. Come up with a wish list of high-priority modules that Phobos is > missing that would make D a substantially more attractive language than it > is now. > > 3. Figure out who's already working on what from the wish list and what > bottlenecks, if any, are getting in the way and what can be done about them. > > The following is the wish list as I see it. Please suggest additions and > correct any errors, as this is mostly off the top of my head. Also, status > updates if you're working on any of these and anything substantial has > changed would be appreciated. > > * Some higher level networking support, such as HTTP, FTP, etc. (Jonas > Drewsen's CURL wrapper handles a lot of this and may be ready for a second > round of review.) > > * Serialization. (Jacob Carolberg's Orange library might be a good > candidate. IIRC he said it's close to ready for review.) > > * Encryption and hashing. (This is more an implementation problem than a > design problem and AFAIK noone is working on it.) > > * Containers. (AFAIK noone is working on this. It's tough to get > started because, despite lots of discussion at various times on this forum, > noone seems to really know what they want. Since the containers in > question are well-known, it's much more a design problem than an > implementation problem.) > > * Allocators. (I think Phobos desperately needs a segmented stack/region > based allocator and I've written one. I've also tried to define a generic > allocator API, mostly following Andrei's suggestions, but I'll admit that I > didn't really know what I was doing for the general API. Andrei has > suggested that allocators should have real-world testing on containers > before being included in Phobos. Therefore, containers block allocators and > if the same person doesn't write both, there will be a lot of communication > overhead to make sure the designs are in sync.) > > * Streams. (Another item where the bottleneck is mostly at the design > level and people not really knowing what they want.) > > * Compression/archiving. (Opening standard compressed/archived file > formats needs to just work. This includes at least zip, gzip, tar and > bzip2. Of course, zip already is available and gzip is supported by the > zlib module but with a crufty C API. At least gzip and bzip2, which are > stream-based as opposed to file-based, should be handled via streams, which > means that streams block compression/archiving. Also, since tar and zip > are both file based, they should probably be handled by the same API, which > might mean deprecating std.zip and rewriting it.) > > * An improved std.xml. (I think Thomas Sowinski is working on a > replacement, but I haven't seen any updates in a long time.) > > * Matrices and linear algebra. (Cristi Cobzarenco's GSoC project is a > good starting point but it needs polish. I've been in contact with him > occasionally since GSoC ended and he indicated that he wants to get back to > working on it but doesn't have time. I've contributed to it sparingly, but > find it difficult because I haven't gotten around to familiarizing myself > with the implementation details yet, and it's hard to get into a project > that complex with a few hours a week as opposed to focusing full time on > it.) > > * std.database. (Apparently Steve Teale is working on this. This is a > large, complicated project because we're trying to define a common API for > a variety of RDBMSs. Again, it's more a design problem than an > implementation problem.) > > * Better support for creating processes/new std.process. (Lars > Kyllingstad wrote a replacement candidate for Posix and Steve Schveighoffer > ported it to Windows, but issues with the DMC runtime prevent it from > working on Windows.) > > * Parallel algorithms. (I've implemented a decent amount of these in my > std.parallel_algorithm Github project, but I've become somewhat frustrated > and unmotivated to finish this project because so many of the relevant > algorithms seem memory bandwidth bound and aren't substantially faster when > parallelized than when run serially.) > > After writing this, the general pattern I notice is that lots of stuff is > blocked by design, not implementation. In a lot of cases people don't > really know what they want and analysis paralysis results. >
As a console/embedded games developer, my top 4: *Allocators* - +1 .. GC is lovely to have, but in many cases, I need strict control over my memory management. Any libraries that use the GC internally are potentially unusable to me in some applications. *Low level/hardware vector-maths library* - This is kinda blocked by the lack of support for an intrinsic vector type in the compiler... the language needs at very least a 128bit vector type to express the registers and make it possible to allocate them in structures, and pass them between functions. Architecture specific compilers/libraries can then build on top of that, and then ideally, a low level maths library in Phobos might collate various architectures vector hardware support into a common API. I would happily volunteer to to handle this, but I need at least a 128bit hardware vector type in the language first (GDC has this though proprietary extension, rather, the language should define a standard). I guess I could design the API without it, but the library would only really work efficiently on flavours of GCC. *Crypto *- +1 as mentioned above, blocked on streams... *Higher level maths/signal processing *- The linear algebra library mentioned in a previous post might be very useful, but also standard algorithms like fourier transforms. Library implementations of these would be amazing, potentially making use of hardware back ends where possible.
