Re: std.stdio overhaul by Steve Schveighoffer
On Tuesday, September 06, 2011 08:42:14 Jacob Carlborg wrote: > On 2011-09-06 08:00, Walter Bright wrote: > > On 9/5/2011 7:48 PM, Andrei Alexandrescu wrote: > >> I agree with all of the above. However, as is often the case, there's > >> more than > >> one side to the story. > >> > >> Bad APIs have their costs too. We can't afford to have an XML library > >> that > >> offers few and badly packaged features and comes at the tail of all > >> benchmarks. > >> We also can't afford a JSON library that is poorly designed and badly > >> written. > >> Ironically, the costs mostly manifest the same way: people will decide > >> not to > >> use D because it "lacks good libraries" and "is quirky to use". In > >> many ways a > >> language's standard library is a showcase of the language, and to a > >> newcomer an > >> inconsistent and awkward standard library affects the perception of > >> the > >> language's quality. > > > > I agree that the XML and JSON libraries need to be scrapped and > > rewritten. But simply changing the names of otherwise successful APIs is > > not worth while. > > So we have to live with these naming conventions from C forever? My take on it is that we need to figure out which pieces of Phobos need to be reworked or renamed and get it done as soon as possible. That way, everything follows the proper naming conventions (thus avoiding a mess like PHP) and is of an appropriately high level of quality. Then we can have an appropriately stable API which doesn't have to change often - if at all. I think that the current problem with Phobos is primarily a combination of three things: 1. Older APIs which aren't in line with how D2 and Phobos have evolved (e.g. they don't use ranges when they should). 2. Some older stuff didn't get a thorough enough peer review before making it into Phobos and is not at a high enough level of quality, so it needs to be revised or replaced. 3. Too much of what has been done in the past has been a hodgepodge of naming conventions, making it very inconsistent in some places. Once those have been sorted out (some of which can be done without breaking any existing code and some of which requires breaking changes), then we can have a stable API for Phobos which doesn't change much except where we're adding new functionality which doesn't break existing code. So ultimately, we _will_ have a stable API, but some breaking changes are required in the short term to resolve issues with Phobos which would cause problems in the long run. - Jonathan M Davis
Re: std.stdio overhaul by Steve Schveighoffer
On 2011-09-06 08:00, Walter Bright wrote: On 9/5/2011 7:48 PM, Andrei Alexandrescu wrote: I agree with all of the above. However, as is often the case, there's more than one side to the story. Bad APIs have their costs too. We can't afford to have an XML library that offers few and badly packaged features and comes at the tail of all benchmarks. We also can't afford a JSON library that is poorly designed and badly written. Ironically, the costs mostly manifest the same way: people will decide not to use D because it "lacks good libraries" and "is quirky to use". In many ways a language's standard library is a showcase of the language, and to a newcomer an inconsistent and awkward standard library affects the perception of the language's quality. I agree that the XML and JSON libraries need to be scrapped and rewritten. But simply changing the names of otherwise successful APIs is not worth while. So we have to live with these naming conventions from C forever? -- /Jacob Carlborg
Re: std.stdio overhaul by Steve Schveighoffer
On 2011-09-06 04:48, Andrei Alexandrescu wrote: I agree with all of the above. However, as is often the case, there's more than one side to the story. Bad APIs have their costs too. We can't afford to have an XML library that offers few and badly packaged features and comes at the tail of all benchmarks. We also can't afford a JSON library that is poorly designed and badly written. Ironically, the costs mostly manifest the same way: people will decide not to use D because it "lacks good libraries" and "is quirky to use". In many ways a language's standard library is a showcase of the language, and to a newcomer an inconsistent and awkward standard library affects the perception of the language's quality. Stressing that breaking code has a cost and implying that keeping it with flaws has no cost is as mistaken as worrying in chess about the flank at the expense of the center. The reality we need to face is, we are experiencing growth pains. What we must do is NOT lament about breaking this or keeping that. We must: a) devise good language features to cope with deprecation, of which deprecation with message is one that I think we need to embrace and extend (I have a few ideas I'll discuss separately); b) supplement that with a good policy for deprecating APIs and introducing new ones - in particular decide where to draw the line when introducing a breaking change; c) possibly create programs a la gofix that help migration. Andrei We don't want to have a standard library like the one in PHP where there seems to be no naming conventions at all. -- /Jacob Carlborg
Re: Review Queue: std.log, std.regionallocator, or something else?
On 2011-09-06 02:33, dsimcha wrote: == Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article dsimcha, is there any reason not to start the review of the region allocator shortly? Does a review period of about 2 weeks, ending on Wednesday, the 21st sound good? - Jonathan M Davis Sounds perfect. Thanks. A few issues that I'd like mentioned in the initial announcement because they need to be examined: 1. This is both a proposal for RegionAllocator and a proposal for a more general allocator API in Phobos. The allocator API will be a structural interface that includes the intersection of gcallocator and regionallocator functionality. I don't have a more precise definition yet. Hopefully the review process will hammer out whatever ambiguities remain. 2. Should we put this stuff in a std.allocators package, in a single std.allocators module, or something else? We should put this stuff in a std.allocators package, we definitely do NOT want yet another enormous module, yes I'm looking at you std.datetime. 3. We definitely want a reap (combination region and heap) eventually, though I don't have one yet. I want RegionAllocator to be reviewed for anything that would make it unnecessarily hard to write other allocators on top of it, most importantly reaps but also free lists, etc. -- /Jacob Carlborg
Re: std.stdio overhaul by Steve Schveighoffer
On 9/5/2011 7:48 PM, Andrei Alexandrescu wrote: I agree with all of the above. However, as is often the case, there's more than one side to the story. Bad APIs have their costs too. We can't afford to have an XML library that offers few and badly packaged features and comes at the tail of all benchmarks. We also can't afford a JSON library that is poorly designed and badly written. Ironically, the costs mostly manifest the same way: people will decide not to use D because it "lacks good libraries" and "is quirky to use". In many ways a language's standard library is a showcase of the language, and to a newcomer an inconsistent and awkward standard library affects the perception of the language's quality. I agree that the XML and JSON libraries need to be scrapped and rewritten. But simply changing the names of otherwise successful APIs is not worth while. c) possibly create programs a la gofix that help migration. gofix cannot fix books, articles, blogs, and presentations. Furthermore, in order to work successfully, gofix needs to be a complete D front end, capable of handling both the old and the new stuff. Doing a perl script would be a disaster. It's a substantial project, has a high risk of inadequacy, and I suspect our resources are better spent elsewhere. Considering also the problems people have running dmd and getting it to find their imports and libraries, add in having to run 'gofix' over their source code first, then patch up what gofix goofed up, seems a stretch.
Re: std.stdio overhaul by Steve Schveighoffer
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article > In many ways a language's standard library is a > showcase of the language, YES!!! I'm glad someone besides me finally realizes this. For example, whenever someone asks me about why D metaprogramming is so great, I just point them to a few std lib modules that showcase this, e.g.: http://stackoverflow.com/questions/7300298/metaprogramming-in-c-and-in-d/7300611#7300611
Re: std.stdio overhaul by Steve Schveighoffer
On Tue, Sep 6, 2011 at 12:48 PM, Andrei Alexandrescu wrote: > On 09/05/2011 04:51 PM, Walter Bright wrote: >>> >>> If the new std.path breaks existing code, I need to fix it before it is >>> released. Please let me know what problems you are experiencing. >> >> It prints out all the deprecation message. It means I'll have to go edit >> existing, working code to change the names. > > I think it means it gives you time, on your own schedule with generous > deadlines, to make the changes to your code. > >> I know that the majority wants the name changes. I know the deprecation >> system gives people plenty of time to edit their code. >> >> But I think the cost of breaking existing code is much higher than many >> realize, and a lot of that cost will be hidden. It'll come in the form >> of people deciding not to use D because it is "not stable". It'll come >> in the form of invalidating existing libraries and modules unless >> someone is regularly maintaining them. It'll come in the form of >> invalidating the mass of books, articles, blog postings, and >> presentations about D, and those will never get updated. People will >> type in the code examples, they will fail to compile, and they'll get >> turned off about D. >> >> I'll again note that I know of know successful operating system or >> programming language that goes around breaking existing code unless it >> is really, really urgent. >> >> Camel-casing a name doesn't meet that standard. So, yes, I don't like it. > > I agree with all of the above. However, as is often the case, there's more > than one side to the story. > > Bad APIs have their costs too. We can't afford to have an XML library that > offers few and badly packaged features and comes at the tail of all > benchmarks. We also can't afford a JSON library that is poorly designed and > badly written. Ironically, the costs mostly manifest the same way: people > will decide not to use D because it "lacks good libraries" and "is quirky to > use". In many ways a language's standard library is a showcase of the > language, and to a newcomer an inconsistent and awkward standard library > affects the perception of the language's quality. > > Stressing that breaking code has a cost and implying that keeping it with > flaws has no cost is as mistaken as worrying in chess about the flank at the > expense of the center. > > The reality we need to face is, we are experiencing growth pains. What we > must do is NOT lament about breaking this or keeping that. We must: > > a) devise good language features to cope with deprecation, of which > deprecation with message is one that I think we need to embrace and extend > (I have a few ideas I'll discuss separately); > > b) supplement that with a good policy for deprecating APIs and introducing > new ones - in particular decide where to draw the line when introducing a > breaking change; > > c) possibly create programs a la gofix that help migration. > > > Andrei > My question is why do you even need a standard API for XML and JSON. Trying to support everything out of the box to a high degree of quality and provide enough generality that it's useful for everybody is just too much work and all you achieve is to discourage alternative implementations better suited to specific needs.
Re: std.stdio overhaul by Steve Schveighoffer
On 09/05/2011 04:51 PM, Walter Bright wrote: If the new std.path breaks existing code, I need to fix it before it is released. Please let me know what problems you are experiencing. It prints out all the deprecation message. It means I'll have to go edit existing, working code to change the names. I think it means it gives you time, on your own schedule with generous deadlines, to make the changes to your code. I know that the majority wants the name changes. I know the deprecation system gives people plenty of time to edit their code. But I think the cost of breaking existing code is much higher than many realize, and a lot of that cost will be hidden. It'll come in the form of people deciding not to use D because it is "not stable". It'll come in the form of invalidating existing libraries and modules unless someone is regularly maintaining them. It'll come in the form of invalidating the mass of books, articles, blog postings, and presentations about D, and those will never get updated. People will type in the code examples, they will fail to compile, and they'll get turned off about D. I'll again note that I know of know successful operating system or programming language that goes around breaking existing code unless it is really, really urgent. Camel-casing a name doesn't meet that standard. So, yes, I don't like it. I agree with all of the above. However, as is often the case, there's more than one side to the story. Bad APIs have their costs too. We can't afford to have an XML library that offers few and badly packaged features and comes at the tail of all benchmarks. We also can't afford a JSON library that is poorly designed and badly written. Ironically, the costs mostly manifest the same way: people will decide not to use D because it "lacks good libraries" and "is quirky to use". In many ways a language's standard library is a showcase of the language, and to a newcomer an inconsistent and awkward standard library affects the perception of the language's quality. Stressing that breaking code has a cost and implying that keeping it with flaws has no cost is as mistaken as worrying in chess about the flank at the expense of the center. The reality we need to face is, we are experiencing growth pains. What we must do is NOT lament about breaking this or keeping that. We must: a) devise good language features to cope with deprecation, of which deprecation with message is one that I think we need to embrace and extend (I have a few ideas I'll discuss separately); b) supplement that with a good policy for deprecating APIs and introducing new ones - in particular decide where to draw the line when introducing a breaking change; c) possibly create programs a la gofix that help migration. Andrei
Re: Review Queue: std.log, std.regionallocator, or something else?
== Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article > dsimcha, is there any reason not to start the review of the region allocator > shortly? Does a review period of about 2 weeks, ending on Wednesday, the 21st > sound good? > - Jonathan M Davis Sounds perfect. Thanks. A few issues that I'd like mentioned in the initial announcement because they need to be examined: 1. This is both a proposal for RegionAllocator and a proposal for a more general allocator API in Phobos. The allocator API will be a structural interface that includes the intersection of gcallocator and regionallocator functionality. I don't have a more precise definition yet. Hopefully the review process will hammer out whatever ambiguities remain. 2. Should we put this stuff in a std.allocators package, in a single std.allocators module, or something else? 3. We definitely want a reap (combination region and heap) eventually, though I don't have one yet. I want RegionAllocator to be reviewed for anything that would make it unnecessarily hard to write other allocators on top of it, most importantly reaps but also free lists, etc.
Re: Review Queue: std.log, std.regionallocator, or something else?
On Wednesday, August 31, 2011 23:56:04 dsimcha wrote: > Unless something has changed, the review of std.curl (formerly etc.curl > but I think there's some agreement now that it should be in std) ends > today. (David Naglinger is the review manager. David, please make this > official.) > > Since we have such an embarrassment of riches lately in terms of new > modules to be reviewed, we don't want bubbles in the review queue. The > first thing we need to decide is whether a review is allowed to run > concurrently with a vote. Andrei has suggested that reviews never run > concurrently with each other, and I agree. However, since the vote > stage takes up much less of the community's time, I think it's ok to run > a review and a vote concurrently with each other. > > Either way, here are the potential modules for next in the review queue. > Which ones are the highest priority and whether I missed any. > > std.log (Logging module by Jose Armando Garcia. High priority because > logging is a standard feature in modern languages.) > > std.regionallocator (A segmented stack/region memory allocator, by me. > I'd like to fast-track this because it's used by two of the GSoC > projects that were done this summer so getting it into Phobos would > simplify things.) > > CSV parser (By Jesse Phillips) > > std.variant (Massive overhaul that includes runtime reflection, by > Robert Jacques.) > > In case you read my last review queue status post, I've taken > std.process out of the pool because it needs a runtime fix on windows > and std.parallel_algorithm because I decided to make it more > comprehensive and need time to do so. Given that no one else other than David Nadlinger (who just was the review manager, so he shouldn't have to do it this time around) has volunteered to be the review manager for the next round, I guess that I'll volunteer to do it. And based on this discussion, it looks like the region allocator is next. dsimcha, is there any reason not to start the review of the region allocator shortly? Does a review period of about 2 weeks, ending on Wednesday, the 21st sound good? - Jonathan M Davis
Re: std.stdio overhaul by Steve Schveighoffer
Count me as another who is sick and tired of the gratuitous breaking changes every damned month. The worst part is there's still some new stuff I actually want each month, so I'm not doing my usual strategy of never, ever, ever updating software. It's just pain. Trivial changes are easy enough to fix, but are a pain. More complex changes cost me time and money. (I'm still angry about the removal of std.date. But soft deprecation is even worse - I hate that so much the first thing I do when updating my dmd is to edit the source to get that useless annoying shit out of there)
Re: std.stdio overhaul by Steve Schveighoffer
Jonathan M Davis: > > Breaking std.stdio, which is used everywhere, this thoroughly needs a very > > high bar of justification. > > Agreed. The purpose of the gofix tool in the Go language library is to lower this bar significantly :-) Bye, bearophile
Re: std.stdio overhaul by Steve Schveighoffer
Andrej Mitrovic: > It would really help out if we had some sort of semi-automated script > that can do at least partial translation of code that uses old phobos > functions to new ones. Maybe this wouldn't work 100% but at least it > would help out. I'm thinking of something similar to what Python 2to3 > does. You mean like the standard tool gofix: http://blog.golang.org/2011/04/introducing-gofix.html Bye, bearophile
Re: RFC: StaticFilter, PApply, Compose, template predicates
On 09/06/2011 12:36 AM, zeljkog wrote:
On 05.09.2011 23:06, Timon Gehr wrote:
The aggregate to loop over is evaluated at compile time:
int[] getAggregate(){return [1,2,3,];}
static foreach(x;getAggregate()) {
pragma(msg,x);
}
Eh :)
For me the only compile time agregate is tuple.
foreach already works with any aggregate at compile time.
int[] getAggregate(){return [1,2,3,];}
mixin({
string r;
foreach(x;getAggregate()) r~="pragma(msg,"~to!string(x)~");";
return r;
}());
What is your point?
We should talk about basic looping construct for compile time evolution.
In CTFE you can use any looping construct you like.
Re: RFC: StaticFilter, PApply, Compose, template predicates
On 05.09.2011 23:06, Timon Gehr wrote:
The aggregate to loop over is evaluated at compile time:
int[] getAggregate(){return [1,2,3,];}
static foreach(x;getAggregate()) {
pragma(msg,x);
}
Eh :)
For me the only compile time agregate is tuple.
We should talk about basic looping construct for compile time evolution.
Re: std.stdio overhaul by Steve Schveighoffer
Am 06.09.2011, 00:05 Uhr, schrieb Andrej Mitrovic : On 9/5/11, Walter Bright wrote: It prints out all the deprecation message. It means I'll have to go edit existing, working code to change the names. It would really help out if we had some sort of semi-automated script that can do at least partial translation of code that uses old phobos functions to new ones. Maybe this wouldn't work 100% but at least it would help out. I'm thinking of something similar to what Python 2to3 does. I know for sure I could use this, so far I've had to fix the DWinSamples for every DMD/Phobos release. It would help to have a lexical analyzer of the kind that allows for the refactorings in for example Eclipse for Java. Without clear identification of symbols it is impossible to write such a script for every new D release. And there were other changes in the past where this would have been handy although I have not writing any D code lately to feel the breakage. I think of globals (__gshared). I'm on the extreme with my urge to rewrite things if they give me the slightest feeling that they could be more elegant or effective and I've thought of such a script as well that could be distributed with every new D version while there are still breaking changes to the language. Well, you cannot write a script without a solid foundation that can reliably identify and refactor symbols. But this doesn't work well for code you copy from blogs. You would have to know what D version it was written with and run the matching chain of conversion scripts. Anyway this feels like some crazy idea that can't make it into existence. Still I have that picture of downloading a new D release and running the obligatory dmdup script to replace deprecated functionality or names with the new versions. Sure at some point 'this is it' and features of D and Phobos become set in stone. "Hello world!" console output is one of those examples that many will try first. I would understand if it breaks between major versions of a language, but not from one revision to the next. YMMV :)
Re: std.stdio overhaul by Steve Schveighoffer
== Quote from Walter Bright (newshou...@digitalmars.com)'s article > On 9/4/2011 2:17 AM, Lars T. Kyllingstad wrote: > I'll again note that I know of know successful operating system or programming > language that goes around breaking existing code unless it is really, really > urgent. > Camel-casing a name doesn't meet that standard. So, yes, I don't like it. I agree that we've been overzealous lately in breaking code to fix small inconsistencies in style, etc. I think in a lot of cases the answer is permanent (or very long term, i.e. several years) soft deprecation, plus a real soft-deprecated language feature. This will lead to cruft accumulation but in some cases this cruft is less bad than the cruft caused by inconsistent naming conventions/style, etc. To make the docs seem less crufty to people browsing, we could even eventually remove the soft-deprecated functionality from the DDoc documentation so that people reading it can't even see the cruft, and move the code to the bottom of the source files so that people don't see it unless they go looking for it. We could also adopt a policy of zero maintenance for features that have been soft-deprecated for long periods of time, i.e. not even if they produce egregiously wrong results, security holes, etc.
Re: Pinball Construction Set creator Bill Budge talks shortly about D and Go
"Paulo Pinto" wrote in message news:j3goop$1kh3$1...@digitalmars.com... > You can read about it here, > http://www.gamasutra.com/view/feature/6470/a_conversation_with_bill_budge.php?print=1 > This interview also ended up published in the Sept 2011 issue of Game Developer Magazine. --- Not sent from an iPhone.
Re: std.stdio overhaul by Steve Schveighoffer
On 9/5/11, Walter Bright wrote: > It prints out all the deprecation message. It means I'll have to go edit > existing, working code to change the names. It would really help out if we had some sort of semi-automated script that can do at least partial translation of code that uses old phobos functions to new ones. Maybe this wouldn't work 100% but at least it would help out. I'm thinking of something similar to what Python 2to3 does. I know for sure I could use this, so far I've had to fix the DWinSamples for every DMD/Phobos release.
Re: RFC: StaticFilter, PApply, Compose, template predicates
Simen Kjaeraas: > Certainly we could sit in a corner and pray to almighty Walter that this be > implemented, Walter did find problems in trying to implement a *full* static foreach. Walter is intelligent, quite experienced, and knows the DMD codebase well, but he's just one person. So maybe if he explains here what those problems were, someone else will find a partial solution... Bye, bearophile
Re: std.stdio overhaul by Steve Schveighoffer
On 9/4/2011 2:17 AM, Lars T. Kyllingstad wrote: On Sat, 03 Sep 2011 18:23:26 -0700, Walter Bright wrote: [I also don't like it that all my code that uses std.path is now broken.] What do you mean by "broken"? That it does not compile or work as expected, or that it spits out a bunch of annoying deprecation messages? If it is any of the former, that was not supposed to happen. The new std.path still contains all the functions of the old std.path and should therefore be backwards compatible. If the new std.path breaks existing code, I need to fix it before it is released. Please let me know what problems you are experiencing. It prints out all the deprecation message. It means I'll have to go edit existing, working code to change the names. I know that the majority wants the name changes. I know the deprecation system gives people plenty of time to edit their code. But I think the cost of breaking existing code is much higher than many realize, and a lot of that cost will be hidden. It'll come in the form of people deciding not to use D because it is "not stable". It'll come in the form of invalidating existing libraries and modules unless someone is regularly maintaining them. It'll come in the form of invalidating the mass of books, articles, blog postings, and presentations about D, and those will never get updated. People will type in the code examples, they will fail to compile, and they'll get turned off about D. I'll again note that I know of know successful operating system or programming language that goes around breaking existing code unless it is really, really urgent. Camel-casing a name doesn't meet that standard. So, yes, I don't like it.
Re: RFC: StaticFilter, PApply, Compose, template predicates
Andrei Alexandrescu: > We need a form of iteration that, just like > static if, plants symbols in the current scope, not in a new scope. > StaticIota is unable to help with that. A good static foreach works outside any functions too (as static if), at global scope. Bye, bearophile
Re: Just wanted to say
On 9/5/11 17:16 EDT, Andrei Alexandrescu wrote: On 9/5/11 14:38 EDT, Steve Teale wrote: I've been using a recent version of D2 along with gtkD and Code::Blocks to redo a quite complicated Windows GUI program I wrote back in the mid 90s with the changes I've though of since then, in an Ubuntu environment. This combination has definitely made me highly productive. D is a joy to use, and so easy to read when I compare it with the numerous GTK+ examples I've had to consult written in Python, PHP, C, and C++ (particularly the latter - how did I use it all those years?). Thanks Walter et al. Steve That's great to know particularly since it comes after a healthy does of scrutiny and skepticism. Thanks! Andrei s/does/dose/ Andrei
Re: Just wanted to say
On 9/5/11 14:38 EDT, Steve Teale wrote: I've been using a recent version of D2 along with gtkD and Code::Blocks to redo a quite complicated Windows GUI program I wrote back in the mid 90s with the changes I've though of since then, in an Ubuntu environment. This combination has definitely made me highly productive. D is a joy to use, and so easy to read when I compare it with the numerous GTK+ examples I've had to consult written in Python, PHP, C, and C++ (particularly the latter - how did I use it all those years?). Thanks Walter et al. Steve That's great to know particularly since it comes after a healthy does of scrutiny and skepticism. Thanks! Andrei
Re: RFC: StaticFilter, PApply, Compose, template predicates
On 09/05/2011 10:43 PM, zeljkog wrote:
On 05.09.2011 21:55, Timon Gehr wrote:
static foreach is part of the design. The only reason it is not in the
compiler (and we have the kludgy foreach that works on tuples) is
because Walter experienced implementation difficulties.
Before implementation somebody must precisely define static foreach,
better to say static looping construct.
It works just like foreach, except that it does not introduce a new
scope and can be used at module and aggregate scope.
Eg:
static foreach(x;0..5) {
mixin("T!x var"~to!string(x)~";");
}
is equivalent to
T!0 var0;
T!1 var1;
T!2 var2;
T!3 var3;
T!4 var4;
The aggregate to loop over is evaluated at compile time:
int[] getAggregate(){return [1,2,3,];}
static foreach(x;getAggregate()) {
pragma(msg,x);
}
writes during compilation:
1
2
3
Re: RFC: StaticFilter, PApply, Compose, template predicates
On 05.09.2011 21:55, Timon Gehr wrote: static foreach is part of the design. The only reason it is not in the compiler (and we have the kludgy foreach that works on tuples) is because Walter experienced implementation difficulties. Before implementation somebody must precisely define static foreach, better to say static looping construct.
Re: RFC: StaticFilter, PApply, Compose, template predicates
On 9/5/11 13:31 EDT, Simen Kjaeraas wrote: On Mon, 05 Sep 2011 13:05:23 +0200, bearophile wrote: Robert Jacques: > Seconded. StaticIota is extremely useful for loop unrolling optimizations, e.g.: vote++ vote-- StaticIota is not the good solution. I have explained why elsewhere: http://d.puremagic.com/issues/show_bug.cgi?id=4085 Certainly we could sit in a corner and pray to almighty Walter that this be implemented, when he's done with the things he wants to do with D. Oooor - we could add StaticIota to Phobos, bypass the problem, and live happily ever after. Yes, static foreach would be nice, but the means to do what it would do, are easily implemented in the language as is. The problem is that StaticIota is not a replacement for static foreach due to scoping issues. We need a form of iteration that, just like static if, plants symbols in the current scope, not in a new scope. StaticIota is unable to help with that. Andrei
Re: RFC: StaticFilter, PApply, Compose, template predicates
On 09/05/2011 08:19 PM, kenji hara wrote: 2011/9/6 Simen Kjaeraas: On Mon, 05 Sep 2011 13:05:23 +0200, bearophile wrote: Robert Jacques: Seconded. StaticIota is extremely useful for loop unrolling optimizations, e.g.: vote++ vote-- StaticIota is not the good solution. I have explained why elsewhere: http://d.puremagic.com/issues/show_bug.cgi?id=4085 Certainly we could sit in a corner and pray to almighty Walter that this be implemented, when he's done with the things he wants to do with D. Oooor - we could add StaticIota to Phobos, bypass the problem, and live happily ever after. Yes, static foreach would be nice, but the means to do what it would do, are easily implemented in the language as is. Agreed to Simen. The foreach statement already has loop unrolling feature. To use it, we can pass a compile-time sequence (like TypeTuple) as its aggregator. I think it is clear language design, and not need more. Then we need staticIota. static foreach is part of the design. The only reason it is not in the compiler (and we have the kludgy foreach that works on tuples) is because Walter experienced implementation difficulties. How would you generate a number of declarations with the current foreach and StaticIota?
Re: Just wanted to say
What kind of app? It would be cool if you would write a blog post about your experience (if you have the free time & would like to do that). :)
Re: RFC: StaticFilter, PApply, Compose, template predicates
On Mon, 05 Sep 2011 19:49:43 +0200, Timon Gehr wrote: On 09/05/2011 07:31 PM, Simen Kjaeraas wrote: On Mon, 05 Sep 2011 13:05:23 +0200, bearophile wrote: Robert Jacques: > Seconded. StaticIota is extremely useful for loop unrolling optimizations, e.g.: vote++ vote-- StaticIota is not the good solution. I have explained why elsewhere: http://d.puremagic.com/issues/show_bug.cgi?id=4085 Certainly we could sit in a corner and pray to almighty Walter that this be implemented, when he's done with the things he wants to do with D. Oooor - we could add StaticIota to Phobos, bypass the problem, and live happily ever after. Yes, static foreach would be nice, but the means to do what it would do, are easily implemented in the language as is. That is some heavy C++ design style reasoning. I disagree. I would heartily welcome static foreach, I'm only saying that rather than wait for the perfect solution (which might never appear) we should work with what we have. -- Simen
Re: StaticFilter, PApply, Compose, template predicates
bearophile wrote:
> Robert Jacques:
>
>>> Seconded. StaticIota is extremely useful for loop unrolling optimizations,
>>> e.g.:
>>
>> vote++
>
> vote--
>
> StaticIota is not the good solution. I have explained why elsewhere:
> http://d.puremagic.com/issues/show_bug.cgi?id=4085
>
> Bye,
> bearophile
vote += 2;
Who said staticIota is only used in static foreach? What if I want to
supply staticMap!(staticToString, staticIota!('a', 'z'+1)) as the default
argument of parameter names for 'naryFun'?
Re: toString or not toString
Am 05.09.2011, 19:51 Uhr, schrieb Sean Kelly : On Sep 3, 2011, at 9:06 PM, Andrei Alexandrescu wrote: On 8/30/11 8:59 PM, Paul D. Anderson wrote: Can someone clarify for me the status and/or direction of string formatting in D? [snip] I agree there are major inefficiencies and composability problems caused by a blind toString() that creates a whole new string without any assistance. So we need to fix that. There are suggestions to add this method to Object: void writeTo(void delegate(const(char)[]) sink, string format = null); Then, the suggestion goes, whether or not we deprecate toString, in the short term it should be implemented in terms of writeTo. There are a few questions raised by this proposal: 1. Okay, this takes care of streaming text. How about streaming in binary format? 2. Since we have a relatively involved "output to text" routine, how about an "input from text" routine? If writeTo is there, where is readFrom? Right. Which is why I've suggested in the past that we may want to use the serialization calls for toString. I'm highly skeptical to say the least :). I know there are languages that serialize solely through text representations of the data, like JavaScript, but I've yet to see this mix work in a systems language. What serialization calls do you refer to? - Marco
Just wanted to say
I've been using a recent version of D2 along with gtkD and Code::Blocks to redo a quite complicated Windows GUI program I wrote back in the mid 90s with the changes I've though of since then, in an Ubuntu environment. This combination has definitely made me highly productive. D is a joy to use, and so easy to read when I compare it with the numerous GTK+ examples I've had to consult written in Python, PHP, C, and C++ (particularly the latter - how did I use it all those years?). Thanks Walter et al. Steve
Re: RFC: StaticFilter, PApply, Compose, template predicates
Simen Kjaeraas: > Yes, static foreach would be nice, but the means to do what it would do, > are easily implemented in the language as is. Notes: - I am not asking for a real static foreach. The main point of bug 4085 is that that even half static foreach is better than the current situation. - "static foreach" is also a way to better document what the code is doing. I sometimes add /*static*/ before foreach to increase readability. - Some purposes/use cases of static foreach are not covered by a staticIota. Bye, bearophile
Re: RFC: StaticFilter, PApply, Compose, template predicates
2011/9/6 Simen Kjaeraas : > On Mon, 05 Sep 2011 13:05:23 +0200, bearophile > wrote: > >> Robert Jacques: >> >>> > Seconded. StaticIota is extremely useful for loop unrolling >>> > optimizations, e.g.: >>> >>> vote++ >> >> vote-- >> >> StaticIota is not the good solution. I have explained why elsewhere: >> http://d.puremagic.com/issues/show_bug.cgi?id=4085 > > Certainly we could sit in a corner and pray to almighty Walter that this be > implemented, when he's done with the things he wants to do with D. Oooor - > we > could add StaticIota to Phobos, bypass the problem, and live happily ever > after. > > Yes, static foreach would be nice, but the means to do what it would do, are > easily implemented in the language as is. Agreed to Simen. The foreach statement already has loop unrolling feature. To use it, we can pass a compile-time sequence (like TypeTuple) as its aggregator. I think it is clear language design, and not need more. Then we need staticIota. Kenji Hara
Re: toString or not toString
On Sep 3, 2011, at 9:06 PM, Andrei Alexandrescu wrote: > On 8/30/11 8:59 PM, Paul D. Anderson wrote: >> Can someone clarify for me the status and/or direction of string >> formatting in D? > [snip] > > I agree there are major inefficiencies and composability problems caused by a > blind toString() that creates a whole new string without any assistance. So > we need to fix that. > > There are suggestions to add this method to Object: > > void writeTo(void delegate(const(char)[]) sink, string format = null); > > Then, the suggestion goes, whether or not we deprecate toString, in the short > term it should be implemented in terms of writeTo. > > There are a few questions raised by this proposal: > > 1. Okay, this takes care of streaming text. How about streaming in binary > format? > > 2. Since we have a relatively involved "output to text" routine, how about an > "input from text" routine? If writeTo is there, where is readFrom? Right. Which is why I've suggested in the past that we may want to use the serialization calls for toString.
Re: RFC: StaticFilter, PApply, Compose, template predicates
On 09/05/2011 07:31 PM, Simen Kjaeraas wrote: On Mon, 05 Sep 2011 13:05:23 +0200, bearophile wrote: Robert Jacques: > Seconded. StaticIota is extremely useful for loop unrolling optimizations, e.g.: vote++ vote-- StaticIota is not the good solution. I have explained why elsewhere: http://d.puremagic.com/issues/show_bug.cgi?id=4085 Certainly we could sit in a corner and pray to almighty Walter that this be implemented, when he's done with the things he wants to do with D. Oooor - we could add StaticIota to Phobos, bypass the problem, and live happily ever after. Yes, static foreach would be nice, but the means to do what it would do, are easily implemented in the language as is. That is some heavy C++ design style reasoning.
Re: toString or not toString
On Sep 3, 2011, at 2:41 AM, Christophe wrote: 1. provide an alias void delegate(const(char)[]) Sink; This should be in std.conv; or std.format;, because nobody wants to add it to every single module and if there is a standard way to handle it, no maintenance programmer will be confused by alias. >>> >>> it needs to go into object.di, because Object needs it. >> >> Object could, in theory, just use delegate(const(char)[]). But I agree >> that putting it in object.di would be the cleanest solution. > > I disagree. void delegate(const(char)[]) means something, whereas Sink > is rather obscure. Providing the alias in the library seems fine, but > providing it in the langage is too much IMO. It would be really great if the new toString call could be compatible with whatever serialization mechanism is added. This probably wouldn't allow the use of format strings though.
Re: RFC: StaticFilter, PApply, Compose, template predicates
On Mon, 05 Sep 2011 13:05:23 +0200, bearophile wrote: Robert Jacques: > Seconded. StaticIota is extremely useful for loop unrolling optimizations, e.g.: vote++ vote-- StaticIota is not the good solution. I have explained why elsewhere: http://d.puremagic.com/issues/show_bug.cgi?id=4085 Certainly we could sit in a corner and pray to almighty Walter that this be implemented, when he's done with the things he wants to do with D. Oooor - we could add StaticIota to Phobos, bypass the problem, and live happily ever after. Yes, static foreach would be nice, but the means to do what it would do, are easily implemented in the language as is. -- Simen
Re: How to Design a Good API and Why it Matters
On 05/09/2011 14:44, Mirko Pilger wrote: anyone has any other good API design resources to share. http://www.amazon.com/API-Design-C-Martin-Reddy/dp/0123850037 At first I worried that this would be too C++ specific, but from what I have seen in the example pages the opening chapters at least are pretty general, with many ideas that are equally applicable to D and code that is (for C++) quite readable. The later chapters do seem to depend on C++ very heavily however, so while they might contain some patterns that D programmers can utilise or even improve upon, I suspect it may be harder to translate. Anyone out there to second this recommendation? A...
Re: How to Design a Good API and Why it Matters
On 2011-09-05 15:09, Alix Pexton wrote: On 05/09/2011 13:11, Jacob Carlborg wrote: Another good read is the book "Clean Code": http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 Thanks for the recommendation! Looks like an interesting read, but my cursory glance through the index on Amazon didn't alight upon anything that specifically applies to API design (feel free to point out anything I may have missed). Might be worth the investment, as it seems to cover a lot of best practice for general coding, documenting and testing tasks ^^ Any others? A... And I would highly recommend it, it's one of the best programming books I've ever read. It's well worth the investment. -- /Jacob Carlborg
Re: How to Design a Good API and Why it Matters
On 2011-09-05 15:09, Alix Pexton wrote: On 05/09/2011 13:11, Jacob Carlborg wrote: Another good read is the book "Clean Code": http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 Thanks for the recommendation! Looks like an interesting read, but my cursory glance through the index on Amazon didn't alight upon anything that specifically applies to API design (feel free to point out anything I may have missed). Might be worth the investment, as it seems to cover a lot of best practice for general coding, documenting and testing tasks ^^ Any others? A... This book is not explicitly about designing good APIs but it is, as you say, about best practice for general coding. If you follow these best practices you will get good APIs, so it's implicitly about designing good APIs. As the slides describe, you always design APIs when writing code. The methods of a class are its API. A few ideas they both share: * Both the slides and the book mention things like the importance of giving classes, methods and variables good names * Both mention that the fewer parameters a method has the better * Both mention that a given abstraction level (class, method, module and so on) should only do one thing and to it well. You shouldn't mix different levels of abstraction There are many ideas like these that both the slides and the book share. -- /Jacob Carlborg
Re: toString or not toString
On 09/05/2011 03:29 PM, Andrei Alexandrescu wrote: On 9/5/11 8:38 AM, Timon Gehr wrote: On 09/04/2011 05:46 AM, Andrei Alexandrescu wrote: On 9/3/11 4:40 PM, Timon Gehr wrote: On 09/03/2011 07:21 PM, Andrei Alexandrescu wrote: On 9/3/11 5:41 AM, Christophe wrote: 1. provide an alias void delegate(const(char)[]) Sink; This should be in std.conv; or std.format;, because nobody wants to add it to every single module and if there is a standard way to handle it, no maintenance programmer will be confused by alias. it needs to go into object.di, because Object needs it. Object could, in theory, just use delegate(const(char)[]). But I agree that putting it in object.di would be the cleanest solution. I disagree. void delegate(const(char)[]) means something, whereas Sink is rather obscure. Providing the alias in the library seems fine, but providing it in the langage is too much IMO. Even in the library "Sink" is too vague to be useful as a top-level symbol. Andrei I am quite sure that useful is the same as short/too vague in this case. Are you suggesting not to add an alias at all? There are vastly better names than Sink. TextSink, TextWriter, StringWriter, StringSink (heh), StringStreamer, ... Andrei 'string' is quite obscure/vague too, if you don't know what it is. The 'string' alias in object.di should probably be renamed to TailImmutableDynamicCharArray. :o) I strongly disagree. In many programming languages, "string" denotes the default abstraction for text representation. "Sink" has nowhere near that brand power. Sure, but that was not a valid argument when the term was introduced. BTW: http://www.google.com/search?channel=fs&q=string&um=1&tbm=isch imho better = shorter, because that is the whole point of providing an alias. 'Sink' stops being vague as soon as people know what it is. That should be quite early. Again I completely disagree with all these three statements, sorry. Why would you want to have an alias if not to relieve people from writing cumbersome boilerplate?
Re: toString or not toString
On 09/05/2011 03:33 PM, Andrei Alexandrescu wrote: On 9/5/11 12:22 AM, Walter Bright wrote: On 9/4/2011 7:34 PM, Andrei Alexandrescu wrote: On 9/4/11 22:20 EDT, kenji hara wrote: 2011/9/4 Andrei Alexandrescu: There are suggestions to add this method to Object: void writeTo(void delegate(const(char)[]) sink, string format = null); I think const void toString(scope void delegate(const(char)[]) sink, string format = null); is more better than that, even if it is different from DIP9. That is already used in std.bigint, std.complex, and std.format already support it. Kenji Hara Works for me. Walter? It'll break every D program. Probably you and I have a different thing in mind. I'm thinking of adding that alongside the existing toString. Thinking more about it, I fear that ascribing the two overloads the same name will cause problems when e.g. a class overrides one overload thus hiding the other. So we should look for a different name. Which? I think writeTo is a suitable name.
Re: How to Design a Good API and Why it Matters
anyone has any other good API design resources to share. http://www.amazon.com/API-Design-C-Martin-Reddy/dp/0123850037
Re: toString or not toString
On 9/5/11 12:22 AM, Walter Bright wrote: On 9/4/2011 7:34 PM, Andrei Alexandrescu wrote: On 9/4/11 22:20 EDT, kenji hara wrote: 2011/9/4 Andrei Alexandrescu: There are suggestions to add this method to Object: void writeTo(void delegate(const(char)[]) sink, string format = null); I think const void toString(scope void delegate(const(char)[]) sink, string format = null); is more better than that, even if it is different from DIP9. That is already used in std.bigint, std.complex, and std.format already support it. Kenji Hara Works for me. Walter? It'll break every D program. Probably you and I have a different thing in mind. I'm thinking of adding that alongside the existing toString. Thinking more about it, I fear that ascribing the two overloads the same name will cause problems when e.g. a class overrides one overload thus hiding the other. So we should look for a different name. Which? Andrei
Re: toString or not toString
On 9/5/11 8:38 AM, Timon Gehr wrote: On 09/04/2011 05:46 AM, Andrei Alexandrescu wrote: On 9/3/11 4:40 PM, Timon Gehr wrote: On 09/03/2011 07:21 PM, Andrei Alexandrescu wrote: On 9/3/11 5:41 AM, Christophe wrote: 1. provide an alias void delegate(const(char)[]) Sink; This should be in std.conv; or std.format;, because nobody wants to add it to every single module and if there is a standard way to handle it, no maintenance programmer will be confused by alias. it needs to go into object.di, because Object needs it. Object could, in theory, just use delegate(const(char)[]). But I agree that putting it in object.di would be the cleanest solution. I disagree. void delegate(const(char)[]) means something, whereas Sink is rather obscure. Providing the alias in the library seems fine, but providing it in the langage is too much IMO. Even in the library "Sink" is too vague to be useful as a top-level symbol. Andrei I am quite sure that useful is the same as short/too vague in this case. Are you suggesting not to add an alias at all? There are vastly better names than Sink. TextSink, TextWriter, StringWriter, StringSink (heh), StringStreamer, ... Andrei 'string' is quite obscure/vague too, if you don't know what it is. The 'string' alias in object.di should probably be renamed to TailImmutableDynamicCharArray. :o) I strongly disagree. In many programming languages, "string" denotes the default abstraction for text representation. "Sink" has nowhere near that brand power. imho better = shorter, because that is the whole point of providing an alias. 'Sink' stops being vague as soon as people know what it is. That should be quite early. Again I completely disagree with all these three statements, sorry. Andrei
Re: How to Design a Good API and Why it Matters
On 05/09/2011 13:11, Jacob Carlborg wrote: Another good read is the book "Clean Code": http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 Thanks for the recommendation! Looks like an interesting read, but my cursory glance through the index on Amazon didn't alight upon anything that specifically applies to API design (feel free to point out anything I may have missed). Might be worth the investment, as it seems to cover a lot of best practice for general coding, documenting and testing tasks ^^ Any others? A...
Re: toString or not toString
On 09/04/2011 05:46 AM, Andrei Alexandrescu wrote: On 9/3/11 4:40 PM, Timon Gehr wrote: On 09/03/2011 07:21 PM, Andrei Alexandrescu wrote: On 9/3/11 5:41 AM, Christophe wrote: 1. provide an alias void delegate(const(char)[]) Sink; This should be in std.conv; or std.format;, because nobody wants to add it to every single module and if there is a standard way to handle it, no maintenance programmer will be confused by alias. it needs to go into object.di, because Object needs it. Object could, in theory, just use delegate(const(char)[]). But I agree that putting it in object.di would be the cleanest solution. I disagree. void delegate(const(char)[]) means something, whereas Sink is rather obscure. Providing the alias in the library seems fine, but providing it in the langage is too much IMO. Even in the library "Sink" is too vague to be useful as a top-level symbol. Andrei I am quite sure that useful is the same as short/too vague in this case. Are you suggesting not to add an alias at all? There are vastly better names than Sink. TextSink, TextWriter, StringWriter, StringSink (heh), StringStreamer, ... Andrei 'string' is quite obscure/vague too, if you don't know what it is. The 'string' alias in object.di should probably be renamed to TailImmutableDynamicCharArray. :o) imho better = shorter, because that is the whole point of providing an alias. 'Sink' stops being vague as soon as people know what it is. That should be quite early.
Re: How to Design a Good API and Why it Matters
On 2011-09-05 11:55, Alix Pexton wrote: I had a quick look through the archives to see if anything about this talk by Joshua Bloch had been posted before, but couldn't find any references. Here are the slides... http://lcsd05.cs.tamu.edu/slides/keynote.pdf I think I remember seeing a (poor quality) video of the presentation too. I'd be interested to hear what people think of these guidelines and if anyone has any other good API design resources to share. A... I basically agree with everything on those slides. Some things are Java specific and don't apply to D. For example, a final class can have public fields since D supports properties. Another good read is the book "Clean Code": http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 -- /Jacob Carlborg
Re: std.stdio overhaul by Steve Schveighoffer
Andrei Alexandrescu Wrote: > http://erdani.com/d/new-stdio/phobos-prerelease/std_stdio.html Ddoc screwed the types, right?
Re: RFC: StaticFilter, PApply, Compose, template predicates
Robert Jacques: > > Seconded. StaticIota is extremely useful for loop unrolling optimizations, > > e.g.: > > vote++ vote-- StaticIota is not the good solution. I have explained why elsewhere: http://d.puremagic.com/issues/show_bug.cgi?id=4085 Bye, bearophile
How to Design a Good API and Why it Matters
I had a quick look through the archives to see if anything about this talk by Joshua Bloch had been posted before, but couldn't find any references. Here are the slides... http://lcsd05.cs.tamu.edu/slides/keynote.pdf I think I remember seeing a (poor quality) video of the presentation too. I'd be interested to hear what people think of these guidelines and if anyone has any other good API design resources to share. A...
