Re: Article discussing Go, could well be D
"Adam D. Ruppe" wrote in message news:isovu6$21k6$1...@digitalmars.com... >I find it interesting that so many people complain about the lack > of libraries. > > > software library: a way to waste a programmer's time > > reinventing wheels: a lie some programmers, who are paid by the > hour, perpetuated so they can justify the "use" of software libraries > > The project could have been done in one day if he just sat down and > got to work. Instead, he made up some bullshit about how reinventing > wheels is bad. > > Thus, he now spends 3 days searching for a library. Another 5 > days trying to make it work. Another 10 days reading the > godawful documentation. A day bitching about the suckiness on the > internet. > > Then, finally, two days to integrate the library into his project. > For bonus points, force the end users to install it too, because > the more time wasted, the better. Yup. There's definitely a lot of cases where pre-made libs are a huge help and a much better option, but I've gotten really fed up with the Anti-NIH Holy Crusaders, largely for the reasons you stated above. (Another good reason to actually embrace NIH-syndrome instead knee-jerking away from it out of principle is for mission-critical things where you can't afford the possibility of being left at the mercey of some outside group.) What you said above is also why I *strongly* believe that good (and I mean *good*) documentation is every bit as important as actually writing/releasing a tool or library in the first place. I've seen so much "already-made" work that's rendered barely-usable due to less-than-stellar documentation (or even worse: bad or non-existant documentation). What's the point out of putting stuff out there if nobody knows how to use it? What's the point of using something if figuring it out and getting it to work takes about as much effort as DIY? That's why (for public projects anyway) I force myself, even if I don't want to, to put all the effort I need to into documentation to make things as easy as possible. Otherwise, all that effort writing the code would likely have been for nothing anyway.
Re: Removing undefined behavior of bitshifts
s_lange wrote: Am 07.06.2011 01:20, schrieb Timon Gehr: I'd much prefer the behavior to be defined as 1<1<<(0x1f&x); (That's what D effectively does during runtime. It is also what the machine code supports, at least in x87). Well, you probably mean what x86 processors do. The behaviour of x86 processors in this regard is (at leas) well defined, but not uniform. It all depends whether you use general-purpose integer instructions or some 64, 128, or 256-bit SIMD instructions (MMX, SSE, AVX). Int denotes 32-bit integers, operations on differently sized integer are analoguous. For general-purpose integer instructions, the following identities hold true: (l<>x == l>>(x & 0x1F)) for any (signed | unsigned) int l and x , regardless whether arithmetical or logical right shifts are used. However, for SIMD integer instructions, things are a little different and the following identities hold true: (l<= 0x20 ? 0 : l>x == (unsigned int)x >= 0x20 ? 0 : l>>x) for any (signed | unsigned) int x and any unsigned int l (using logical right shifts) (l>>x == (unsigned int)x >= 0x20 ? -1 : l>>x) for any (signed | unsigned) int x and any signed int l (using arithmetic right shifts) As of yet, there are only general-pupose integer rotate instructions on x86 processors, and very few other CPUs and µCs actually implement rotate instructions. Really? Itanium, PowerPC, ARM, 6502, Z80, PIC all have rotate instructions. I've never used a processor that didn't.
Re: How about "auto" parameters?
On 6/9/11 9:56 AM, Jonathan M Davis wrote:
I don't think that there's any question that template error messages could be
improved, and they likely will be, but by their very nature, reporting
template-related errors seems to be a difficult task to adequately solve. It's
one of the things that many people complain about with C++. Template
constraints improve the situation considerably.
I don't think the problem is with templates. If I try to compile this:
===
void foo(int param) {
return param * 2;
}
void main() {
foo(3);
}
===
it says:
main.d(2): Error: * has no effect in expression (param * 2)
WTF? Don't make me think. I just really want to know that I'm returning
from a void function and I can't do that.
Let's assign foo(3) to something:
===
void foo(int param) {
return param * 2;
}
void main() {
auto x = foo(3);
}
===
It says:
main.d(2): Error: * has no effect in expression (param * 2)
main.d(6): Error: variable main.main.x voids have no value
main.d(6): Error: expression foo(3) is void and has no value
Really? Voids have no value? That's good to know, I didn't know that
voids have no value.
Mmm... those are messages to be read by the compiler, not by the user.
The compiler is expecting something that's not void and it is getting a
void thing. The message it generates is "Voids has no value".
The problem are not templates or templates messages. The problem is that
the very basic compiler error messages are targeted at the compiler, not
the developer.
And then this:
===
void main() {
const x = 1;
x = 3;
}
===
main.d(3): Error: variable main.main.x cannot modify const
What do you mean when you say that the variable x cannot modify const?
Wait, I desguise myself as Tarzan and now I understand. It should be
"Error: trying to modify const variable main.main.x".
There is an excellent book called "Don't make me think". When I see
"variable main.main.x cannot modify const" I have to think a little to
understand that that means "variable main.main.x is const and cannot be
modified". Don't make me think. :-)
Re: UFCS idea
On Wed, Jun 8, 2011 at 12:41 PM, Alex_Dovhal wrote: > There have been several topics discussing UFCS recently. So here is one > more) > One idea about UFCS - mark UFCS argument with @, @_, or _ symbol, > e.g. you have some function: > void func(Type1 p1, Type2 p2); > > and later call it: > fucn(a, b); //or > a.func(@_, b); //or > b.func(a, @_); > > This way Timon Gehr's example: >take(10,stride(2,cycle([3,2,5,3]))); >[3,2,5,3].cycle().stride(2).take(10); > would be written as this: >[3,2,5,3].cycle(@_).stride(2, @_).take(10, @_); > > Which is a little longer. On the other side this way benefits from: > * UFCS is directly seen by both the programmer and compiler; > * UFCS doesn't mix with member call syntax; > * UFCS can be used for any type and for any argument, e.g. >a.func(@, b) or b.func(a, @); > * UFCS can be used for more than one argument: a.func(@_, @_~[1]); > > What do you think? > > > I find it funny that @ was initially adopted for annotations, to be used similar to Java and Scala. I come from that world, and one of the rules for annotations is that they cannot directly alter the code the compiler outputs. You can add plugins to the Java compiler that use annotations to modify the AST before it's compiled, and you can use annotations for runtime bytecode generation or interpret them using reflection, but if you take unannotated code and annotated code and compile it (without altering the compiler), the generated code will not change. The idea was to make them a part of the language composed entirely of metadata (some of which was enforced to be correct by the compiler) that could be completely ignored if the programmer didn't want to use it. Now that D has taken up this syntax, we've done almost the opposite. @ is mostly used in situations where it changes the compiled code, changes the existing language, and is in no way optional. We don't really support user defined metadata, and we can't use what annotations we have as metadata because only the compiler can actually use it. Most of the uses I've seen seem to be a way to cram more keywords into the language without adding more keywords. I've been holding in this sort of rant for a while, but in summary, my response is that unless the desired use for @ was defined radically differently by D when it was adopted (and, as far as I can tell, it wasn't), seeing another abuse of it just makes me feel slightly sick inside.
Re: Article discussing Go, could well be D
"Jeff Nowakowski" wrote in message news:ispo9o$f4e$1...@digitalmars.com... > On 06/08/2011 03:55 PM, Nick Sabalausky wrote: >> >> It's not that I have anything against Pike or Thompson. I don't. I >> just think that as dumb as it is to use ad hominem reasoning in the >> first place, it's even dumber to invoke it in such an anachronistic >> way. > > Then don't do it yourself. Your Pike bashing was uncalled for. The > author didn't say anything about Pike except to mention him as one of > the original developers. If he was gushing over the man or saying Go is > worthwhile because of him, then you'd have a point. Once again, I wasn't Pike-bashing. You're misinterpreting my words and assuming I did. Billions of people, obviously myself included, have never done *anything* of real significant note whether recently or 800 years ago. And everyone knows that. So how the heck can saying "some guy who did something significant 40 years ago and hasn't done a damn thing of note since" even *possibly* be taken as an insult? So what if he hasn't? Most people don't do a damn thing of note their entire lives. I'll probably never do a damn thing of note my entire life (even as much as I try). Who cares? It's just fact (well, aside from the definition of "noteworthy" being a bit vague). The only thing my statement *could* rationally be taken as is that I'm just simply *not* praising him. Not praising someone is hardly the same as insulting them (unless you consider them some deity). Again, my entire point for even bringing it up was that the association with "Google/Pike/Thompson" (plus all the "buzz" around the language, which all boils down to little more than "It's Google/Pike/Thompson!" anyway) seems to be his only real reason for giving Issue 9 a real chance and dismissing D outright. Which is, yes, anachronistic ad hominem reasoning. And considering the actual realities of both D and Issue 9, I can't think of anything else besides that "buzz/fame factor" for why he would reject D as being so much more "irrelevant" than Issue 9.
Re: Article discussing Go, could well be D
"Jeff Nowakowski" wrote in message news:ispo9o$f4e$1...@digitalmars.com... > On 06/08/2011 03:55 PM, Nick Sabalausky wrote: >> >> It's not that I have anything against Pike or Thompson. I don't. I >> just think that as dumb as it is to use ad hominem reasoning in the >> first place, it's even dumber to invoke it in such an anachronistic >> way. > > Then don't do it yourself. Your Pike bashing was uncalled for. The > author didn't say anything about Pike except to mention him as one of > the original developers. If he was gushing over the man or saying Go is > worthwhile because of him, then you'd have a point. And no, the author wasn't *just* mentioning him as one one the original creators: "I was a bit skeptical when I read about Google's new programming language. I simply ignored the news. After all, the next New Great Language is just around the corner. Some of them enjoy a phase of hype, but then fade again, others stay in the spheres of irrelevancy [Linked to the D homepage], while yet others will be ready for public consumption any decade now. Some time later I stumbled over it again. This time I took a closer look. One thing I didn't notice at first: One of the inventors is Ken Thompson of Unix and Plan9 fame, and he was indirectly involved with C as well. Now if a new programming language is designed by someone who already served in the trenches of the great mainframe era, maybe there is something to it." So he flat out *states* that he passed over D and gave Issue 9 a try *because* of what was done decades ago by one of the people involved.
Re: UFCS idea
On 2011-06-09 00:20, Andrew Wiley wrote: > On Wed, Jun 8, 2011 at 12:41 PM, Alex_Dovhal wrote: > > There have been several topics discussing UFCS recently. So here is one > > more) > > One idea about UFCS - mark UFCS argument with @, @_, or _ symbol, > > e.g. you have some function: > > void func(Type1 p1, Type2 p2); > > > > and later call it: > > fucn(a, b); //or > > a.func(@_, b); //or > > b.func(a, @_); > > > > This way Timon Gehr's example: > >take(10,stride(2,cycle([3,2,5,3]))); > >[3,2,5,3].cycle().stride(2).take(10); > > > > would be written as this: > >[3,2,5,3].cycle(@_).stride(2, @_).take(10, @_); > > > > Which is a little longer. On the other side this way benefits from: > > * UFCS is directly seen by both the programmer and compiler; > > * UFCS doesn't mix with member call syntax; > > * UFCS can be used for any type and for any argument, e.g. > > > >a.func(@, b) or b.func(a, @); > > > > * UFCS can be used for more than one argument: a.func(@_, @_~[1]); > > > > What do you think? > > I find it funny that @ was initially adopted for annotations, to be used > similar to Java and Scala. I come from that world, and one of the rules for > annotations is that they cannot directly alter the code the compiler > outputs. You can add plugins to the Java compiler that use annotations to > modify the AST before it's compiled, and you can use annotations for > runtime bytecode generation or interpret them using reflection, but if you > take unannotated code and annotated code and compile it (without altering > the compiler), the generated code will not change. > The idea was to make them a part of the language composed entirely of > metadata (some of which was enforced to be correct by the compiler) that > could be completely ignored if the programmer didn't want to use it. > Now that D has taken up this syntax, we've done almost the opposite. @ is > mostly used in situations where it changes the compiled code, changes the > existing language, and is in no way optional. We don't really support user > defined metadata, and we can't use what annotations we have as metadata > because only the compiler can actually use it. Most of the uses I've seen > seem to be a way to cram more keywords into the language without adding > more keywords. > I've been holding in this sort of rant for a while, but in summary, my > response is that unless the desired use for @ was defined radically > differently by D when it was adopted (and, as far as I can tell, it > wasn't), seeing another abuse of it just makes me feel slightly sick > inside. As it is, user-defined attributes can be added later using the @ syntax. True, all of the current uses of @ are for where we decided to save a keyword, but that doesn't stop user-defined attributes from using the syntax later. It just means that those that are currently defined will always be special. Regardless, I see little point in using it for UFCS. If we want to specifically mark parameters for it, I think that the suggestion of using "this" makes a lot more sense. You wouldn't even have to change the grammar (unlike if you used @). You'd just change the semantic phase to treat "this" specially as a function parameter and not freak out about it being a keyword. Using @ would be a much bigger language change and for no gain whatsoever as far as I can see. - Jonathan M Davis
Re: How about "auto" parameters?
On 2011-06-09 00:19, Ary Manzana wrote:
> On 6/9/11 9:56 AM, Jonathan M Davis wrote:
> > I don't think that there's any question that template error messages
> > could be improved, and they likely will be, but by their very nature,
> > reporting template-related errors seems to be a difficult task to
> > adequately solve. It's one of the things that many people complain about
> > with C++. Template constraints improve the situation considerably.
>
> I don't think the problem is with templates. If I try to compile this:
>
> ===
> void foo(int param) {
>return param * 2;
> }
>
> void main() {
>foo(3);
> }
> ===
>
> it says:
>
> main.d(2): Error: * has no effect in expression (param * 2)
>
> WTF? Don't make me think. I just really want to know that I'm returning
> from a void function and I can't do that.
>
> Let's assign foo(3) to something:
>
> ===
> void foo(int param) {
>return param * 2;
> }
>
> void main() {
>auto x = foo(3);
> }
> ===
>
> It says:
>
> main.d(2): Error: * has no effect in expression (param * 2)
> main.d(6): Error: variable main.main.x voids have no value
> main.d(6): Error: expression foo(3) is void and has no value
>
> Really? Voids have no value? That's good to know, I didn't know that
> voids have no value.
>
> Mmm... those are messages to be read by the compiler, not by the user.
> The compiler is expecting something that's not void and it is getting a
> void thing. The message it generates is "Voids has no value".
>
> The problem are not templates or templates messages. The problem is that
> the very basic compiler error messages are targeted at the compiler, not
> the developer.
>
> And then this:
>
> ===
> void main() {
>const x = 1;
>x = 3;
> }
> ===
>
> main.d(3): Error: variable main.main.x cannot modify const
>
> What do you mean when you say that the variable x cannot modify const?
> Wait, I desguise myself as Tarzan and now I understand. It should be
> "Error: trying to modify const variable main.main.x".
>
> There is an excellent book called "Don't make me think". When I see
> "variable main.main.x cannot modify const" I have to think a little to
> understand that that means "variable main.main.x is const and cannot be
> modified". Don't make me think. :-)
Template error messages _do_ tend to be hideous. But that doesn't mean that
normal errors are the best either. And as I said, templates often end up
reporting exactly the same errors that you'd get if you wrote the code by
hand, it's just that the errors are then in the template and generally harder
to understand, because there's a good chance that it's not the code that you
write.
But regardless, none of these error messages are intended to be "read by the
compiler." They're all intended to be read by humans. It's just that you don't
find the choice of wording to be particularly understandable. However,
everything that it's saying is correct. If you find particular error messages
to be bad - particularly if you can think of better alternatives - then create
enhancement requests for them in bugzilla. Then perhaps we'll get better error
messages. But remember that the compiler doesn't know what you're trying to
do. It only knows what you told it to do, so its messages tend to be targetted
at telling you that what you're doing isn't working rather than telling you
what you should be doing instead. So, error messages are often not that great
simply because the compiler is not a mind-reader. Still, if you have
suggestions for improvements to error messages, please submit them to bugzilla
so that the error messages can be improved.
- Jonathan M Davis
Re: UFCS idea
On Thu, Jun 9, 2011 at 12:46 AM, Jonathan M Davis wrote: > On 2011-06-09 00:20, Andrew Wiley wrote: > > On Wed, Jun 8, 2011 at 12:41 PM, Alex_Dovhal > wrote: > > > There have been several topics discussing UFCS recently. So here is one > > > more) > > > One idea about UFCS - mark UFCS argument with @, @_, or _ symbol, > > > e.g. you have some function: > > > void func(Type1 p1, Type2 p2); > > > > > > and later call it: > > > fucn(a, b); //or > > > a.func(@_, b); //or > > > b.func(a, @_); > > > > > > This way Timon Gehr's example: > > >take(10,stride(2,cycle([3,2,5,3]))); > > >[3,2,5,3].cycle().stride(2).take(10); > > > > > > would be written as this: > > >[3,2,5,3].cycle(@_).stride(2, @_).take(10, @_); > > > > > > Which is a little longer. On the other side this way benefits from: > > > * UFCS is directly seen by both the programmer and compiler; > > > * UFCS doesn't mix with member call syntax; > > > * UFCS can be used for any type and for any argument, e.g. > > > > > >a.func(@, b) or b.func(a, @); > > > > > > * UFCS can be used for more than one argument: a.func(@_, @_~[1]); > > > > > > What do you think? > > > > I find it funny that @ was initially adopted for annotations, to be used > > similar to Java and Scala. I come from that world, and one of the rules > for > > annotations is that they cannot directly alter the code the compiler > > outputs. You can add plugins to the Java compiler that use annotations to > > modify the AST before it's compiled, and you can use annotations for > > runtime bytecode generation or interpret them using reflection, but if > you > > take unannotated code and annotated code and compile it (without altering > > the compiler), the generated code will not change. > > The idea was to make them a part of the language composed entirely of > > metadata (some of which was enforced to be correct by the compiler) that > > could be completely ignored if the programmer didn't want to use it. > > Now that D has taken up this syntax, we've done almost the opposite. @ is > > mostly used in situations where it changes the compiled code, changes the > > existing language, and is in no way optional. We don't really support > user > > defined metadata, and we can't use what annotations we have as metadata > > because only the compiler can actually use it. Most of the uses I've seen > > seem to be a way to cram more keywords into the language without adding > > more keywords. > > I've been holding in this sort of rant for a while, but in summary, my > > response is that unless the desired use for @ was defined radically > > differently by D when it was adopted (and, as far as I can tell, it > > wasn't), seeing another abuse of it just makes me feel slightly sick > > inside. > > As it is, user-defined attributes can be added later using the @ syntax. > True, > all of the current uses of @ are for where we decided to save a keyword, > but > that doesn't stop user-defined attributes from using the syntax later. It > just > means that those that are currently defined will always be special. > This is the difference in philosophy at the core of my general unhappiness. When Java officially added annotations, they were designed and built to be used for user-defined metadata. We added "Property" to the grammar, celebrated that we had them too, then stopped. The result is that we're throwing around @ as an excuse for language keywords and boasting about how we have annotations when, by the definition of any other language, we simply don't. I guess the best answer from where I'm standing is to start throwing around possible syntaxes for annotation declarations and references to them in compile-time reflection. I just really hope this gets in to D2, so we aren't permanently stuck with "fake annotations." Regardless, I see little point in using it for UFCS. If we want to > specifically mark parameters for it, I think that the suggestion of using > "this" makes a lot more sense. You wouldn't even have to change the grammar > (unlike if you used @). You'd just change the semantic phase to treat > "this" > specially as a function parameter and not freak out about it being a > keyword. > Using @ would be a much bigger language change and for no gain whatsoever > as > far as I can see. > > I agree. The "this" syntax seems far more logical and straightforward.
Re: Discuss here the best article iPad2 contest
On Wed, 2011-06-08 at 20:30 -0700, Walter Bright wrote: [ .. . ] > Here is all the material: What needs to go with this is a statement from each author that they are happy for ACCU to publish the articles in the journals, and for there to be a short introduction from yourself putting the articles in context. Why they exist at all. Why the topics matter. etc. etc. Basically a guest editorial about the articles. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: UFCS idea
"Jonathan M Davis" wote: > Regardless, I see little point in using it for UFCS. If we want to > specifically mark parameters for it, I think that the suggestion of using > "this" makes a lot more sense. You wouldn't even have to change the > grammar > (unlike if you used @). You'd just change the semantic phase to treat > "this" > specially as a function parameter and not freak out about it being a > keyword. > Using @ would be a much bigger language change and for no gain whatsoever > as > far as I can see. > > - Jonathan M Davis Thanks, Dmitry Olshansky has already explained why using "this" is fully suitable. One thing I personally dislike in UFCS is that it's impossible to visually separate it from member call syntax, only by context. But this is only personal taste. Sorry for noise.
Re: UFCS idea
On 2011-06-09 01:15, Andrew Wiley wrote: > On Thu, Jun 9, 2011 at 12:46 AM, Jonathan M Davis wrote: > > On 2011-06-09 00:20, Andrew Wiley wrote: > > > On Wed, Jun 8, 2011 at 12:41 PM, Alex_Dovhal > > > > wrote: > > > > There have been several topics discussing UFCS recently. So here is > > > > one more) > > > > One idea about UFCS - mark UFCS argument with @, @_, or _ symbol, > > > > e.g. you have some function: > > > > void func(Type1 p1, Type2 p2); > > > > > > > > and later call it: > > > > fucn(a, b); //or > > > > a.func(@_, b); //or > > > > b.func(a, @_); > > > > > > > > This way Timon Gehr's example: > > > >take(10,stride(2,cycle([3,2,5,3]))); > > > >[3,2,5,3].cycle().stride(2).take(10); > > > > > > > > would be written as this: > > > >[3,2,5,3].cycle(@_).stride(2, @_).take(10, @_); > > > > > > > > Which is a little longer. On the other side this way benefits from: > > > > * UFCS is directly seen by both the programmer and compiler; > > > > * UFCS doesn't mix with member call syntax; > > > > * UFCS can be used for any type and for any argument, e.g. > > > > > > > >a.func(@, b) or b.func(a, @); > > > > > > > > * UFCS can be used for more than one argument: a.func(@_, @_~[1]); > > > > > > > > What do you think? > > > > > > I find it funny that @ was initially adopted for annotations, to be > > > used similar to Java and Scala. I come from that world, and one of the > > > rules > > > > for > > > > > annotations is that they cannot directly alter the code the compiler > > > outputs. You can add plugins to the Java compiler that use annotations > > > to modify the AST before it's compiled, and you can use annotations > > > for runtime bytecode generation or interpret them using reflection, > > > but if > > > > you > > > > > take unannotated code and annotated code and compile it (without > > > altering the compiler), the generated code will not change. > > > The idea was to make them a part of the language composed entirely of > > > metadata (some of which was enforced to be correct by the compiler) > > > that could be completely ignored if the programmer didn't want to use > > > it. Now that D has taken up this syntax, we've done almost the > > > opposite. @ is mostly used in situations where it changes the compiled > > > code, changes the existing language, and is in no way optional. We > > > don't really support > > > > user > > > > > defined metadata, and we can't use what annotations we have as metadata > > > because only the compiler can actually use it. Most of the uses I've > > > seen seem to be a way to cram more keywords into the language without > > > adding more keywords. > > > I've been holding in this sort of rant for a while, but in summary, my > > > response is that unless the desired use for @ was defined radically > > > differently by D when it was adopted (and, as far as I can tell, it > > > wasn't), seeing another abuse of it just makes me feel slightly sick > > > inside. > > > > As it is, user-defined attributes can be added later using the @ syntax. > > True, > > all of the current uses of @ are for where we decided to save a keyword, > > but > > that doesn't stop user-defined attributes from using the syntax later. It > > just > > means that those that are currently defined will always be special. > > This is the difference in philosophy at the core of my general unhappiness. > When Java officially added annotations, they were designed and built to be > used for user-defined metadata. We added "Property" to the grammar, > celebrated that we had them too, then stopped. The result is that we're > throwing around @ as an excuse for language keywords and boasting about how > we have annotations when, by the definition of any other language, we > simply don't. > I guess the best answer from where I'm standing is to start throwing around > possible syntaxes for annotation declarations and references to them in > compile-time reflection. I just really hope this gets in to D2, so we > aren't permanently stuck with "fake annotations." I don't really see anything wrong with leaving the current @ attributes as they are and then just using @ for user-defined attributes as well. There will just be a set of attribute names which are reserved by the compiler. All that using a different syntax for user-defined attributes would buy you would be that you could use the attribute names that the compiler has reserved - safe, trusted, system, and property. And that isn't exactly a huge gain. We might as well just use @ for user-defined attributes as well. - Jonathan M Davis
Re: Best article vote tally - WE HAVE TWO WINNERS!
On 09/06/2011 02:57, Brad Roberts wrote: > On Wed, 8 Jun 2011, Moritz Warning wrote: > >> Congratulations to both winners! >> Pfft, if I have had time to vote, I might have >> robbed one of his prize (sorry Brad). :) > > I hadn't brought it up yet, but the fact that there were only 25 votes > is, really, fairly sad. I too didn't vote. I know this community is > _far_ larger than 25 people. Heck, even the number of posters to this > forum is larger. > > Why? Not allowed to. I'm reading the D groups for a few months now but never posted before.
Re: How about "auto" parameters?
On Jun 9, 11 15:54, Jonathan M Davis wrote: Template error messages_do_ tend to be hideous. But that doesn't mean that normal errors are the best either. And as I said, templates often end up reporting exactly the same errors that you'd get if you wrote the code by hand, it's just that the errors are then in the template and generally harder to understand, because there's a good chance that it's not the code that you write. But regardless, none of these error messages are intended to be "read by the compiler." They're all intended to be read by humans. It's just that you don't find the choice of wording to be particularly understandable. However, everything that it's saying is correct. If you find particular error messages to be bad - particularly if you can think of better alternatives - then create enhancement requests for them in bugzilla. Then perhaps we'll get better error messages. But remember that the compiler doesn't know what you're trying to do. It only knows what you told it to do, so its messages tend to be targetted at telling you that what you're doing isn't working rather than telling you what you should be doing instead. So, error messages are often not that great simply because the compiler is not a mind-reader. Still, if you have suggestions for improvements to error messages, please submit them to bugzilla so that the error messages can be improved. - Jonathan M Davis Actually, this is an old bug. http://d.puremagic.com/issues/show_bug.cgi?id=3922
Re: UFCS idea
Andrew Wiley Wrote: > celebrated that we had them too, then stopped. The result is that we're > throwing around @ as an excuse for language keywords and boasting about how > we have annotations when, by the definition of any other language, we simply > don't. By "any other language" you must mean C# :)
Re: copyright - are version(GPL) libs acceptable?
> Maybe(!) it's better to just supply interfaces That's all I had in mind - it's just meant to reduce the barrier to entry a little.
Re: copyright - are version(GPL) libs acceptable?
David Nadlinger wrote: > Just write a nice package manager for D? ;) I already did! (a little 100 line program based on the same idea as rdmd, but adding automatic http downloads for missing imports) It does everything I'd want, but not enough for most other people, so I'm looking for a simple step for them.
Re: Article discussing Go, could well be D
Nick Sabalausky wrote: > (or even worse: bad or non-existant documentation) Actually, I think no doc is better than bad doc. At least with no docs, you're immediately informed to not waste your time trying to read it! I work with a lot of web apps. I wish they were completely undocumented; that'd be better than spending an hour reading something just to find it is completely wrong! (The worst part is we're conditioned to think other people's code is generally more correct than your code. So when a problem comes up, you blame yourself and spend hours tilting at windmills...)
Re: Best article vote tally - WE HAVE TWO WINNERS!
On Thu, 09 Jun 2011 06:31:50 -0400, Johannes Totz wrote: On 09/06/2011 02:57, Brad Roberts wrote: On Wed, 8 Jun 2011, Moritz Warning wrote: Congratulations to both winners! Pfft, if I have had time to vote, I might have robbed one of his prize (sorry Brad). :) I hadn't brought it up yet, but the fact that there were only 25 votes is, really, fairly sad. I too didn't vote. I know this community is _far_ larger than 25 people. Heck, even the number of posters to this forum is larger. Why? Not allowed to. I'm reading the D groups for a few months now but never posted before. Now you can vote in the next one :) -Steve
Instantiating Templates Structs with defaults parameter
Greetings
Kindly look at the code below. When I try to compile it with DMD 2-53, I get
an error:
foo.d(9): Error: struct template.Foo(int n = 1) is used as a type
It would be convenient if I am allowed to use Foo as a type without passing
parameters (with parameterized functions that is the default behavior). I
want to understand if not being able to instantiate Foo with default
parameters is a bug in DMD? Otherwise If it is not allowed in D2, I want to
know why such a limitation is there.
Regards
- Puneet
import std.stdio;
struct Foo(int n = 1) {
public int value = n;
}
void main()
{
Foo foo; // Does not compile
// Foo!() foo; // This works
writeln("Value is, ", foo.value);
}
Re: Instantiating Templates Structs with defaults parameter
d coder wrote:
> Greetings
>
> Kindly look at the code below. When I try to compile it with DMD 2-53, I get
> an error:
>
> foo.d(9): Error: struct template.Foo(int n = 1) is used as a type
>
> It would be convenient if I am allowed to use Foo as a type without passing
> parameters (with parameterized functions that is the default behavior). I
> want to understand if not being able to instantiate Foo with default
> parameters is a bug in DMD? Otherwise If it is not allowed in D2, I want to
> know why such a limitation is there.
>
> Regards
> - Puneet
>
> import std.stdio;
>
> struct Foo(int n = 1) {
> public int value = n;
> }
>
> void main()
> {
> Foo foo; // Does not compile
> // Foo!() foo; // This works
> writeln("Value is, ", foo.value);
> }
I don't know whether this should compile but there is a simple work
around:
alias Foo!() Bar;
and then
Bar bar;
works as expected.
Does it help?
Jens
Re: Instantiating Templates Structs with defaults parameter
> > > I don't know whether this should compile but there is a simple work > around: > > alias Foo!() Bar; > > and then > > Bar bar; > > works as expected. > Does it help? > > Actually it does not. Actually I am trying to create a DESL. For me this Foo Bar stuff kind of becomes user interface. Regards - Puneet
D Recurrences
Hey,
Shouldn't both these programs output the fibonnacci numbers? Only the
first one does.
import std.range;
import std.stdio;
int main() {
auto a = recurrence!("a[n-1] + a[n-2]")(0,1);
int i = 0;
foreach(int n; a) {
if(i++ > 20) break;
writefln("%d", n);
}
return 0;
}
import std.range;
import std.stdio;
int main() {
auto a = recurrence!("a[n-1] + (n < 2 ? 0 : a[n-2])")(1);
int i = 0;
foreach(int n; a) {
if(i++ > 20) break;
writefln("%d", n);
}
return 0;
}
Re: D Recurrences
On 09/06/11 16:19, Ben Grabham wrote:
Hey,
Shouldn't both these programs output the fibonnacci numbers? Only the
first one does.
import std.range;
import std.stdio;
int main() {
auto a = recurrence!("a[n-1] + a[n-2]")(0,1);
int i = 0;
foreach(int n; a) {
if(i++ > 20) break;
writefln("%d", n);
}
return 0;
}
import std.range;
import std.stdio;
int main() {
auto a = recurrence!("a[n-1] + (n < 2 ? 0 : a[n-2])")(1);
int i = 0;
foreach(int n; a) {
if(i++ > 20) break;
writefln("%d", n);
}
return 0;
}
Also, is there a takeWhile function?
I can't find one in the documents...
Re: D Recurrences
Ben Grabham wrote:
> Hey,
>
> Shouldn't both these programs output the fibonnacci numbers? Only the
> first one does.
>
> import std.range;
> import std.stdio;
> int main() {
> auto a = recurrence!("a[n-1] + a[n-2]")(0,1);
> int i = 0;
> foreach(int n; a) {
> if(i++ > 20) break;
> writefln("%d", n);
> }
> return 0;
> }
>
>
>
> import std.range;
> import std.stdio;
> int main() {
> auto a = recurrence!("a[n-1] + (n < 2 ? 0 : a[n-2])")(1);
> int i = 0;
> foreach(int n; a) {
> if(i++ > 20) break;
> writefln("%d", n);
> }
> return 0;
> }
You use the function recurrence incorrectly in the second example: You may only
use a[n-1] to a[n-x] in your formula where x is the number of arguments given to
the template function. It would be nice if the library could enforce this, but
(at
least currently) it cannot.
Timon
Re: copyright - are version(GPL) libs acceptable?
Am 09.06.2011 15:03, schrieb Adam Ruppe: >> Maybe(!) it's better to just supply interfaces > > That's all I had in mind - it's just meant to reduce the barrier > to entry a little. Ah ok, I thought you wanted to bundle the libs themselves. Just providing the interfaces should be fine, I think - probably even without version(GPL) - because 1. AFAIK the "threshold of originiality" for a Copyright isn't met with just headers/the interfaces (at least in Germany) 2. We wouldn't even use their own headers but newly-written D interfaces that are equivalent to them. Cheers, - Daniel
Re: D Recurrences
On 6/9/11 10:19 AM, Ben Grabham wrote:
Hey,
Shouldn't both these programs output the fibonnacci numbers? Only the
first one does.
import std.range;
import std.stdio;
int main() {
auto a = recurrence!("a[n-1] + a[n-2]")(0,1);
int i = 0;
foreach(int n; a) {
if(i++ > 20) break;
writefln("%d", n);
}
return 0;
}
import std.range;
import std.stdio;
int main() {
auto a = recurrence!("a[n-1] + (n < 2 ? 0 : a[n-2])")(1);
int i = 0;
foreach(int n; a) {
if(i++ > 20) break;
writefln("%d", n);
}
return 0;
}
The second implementation is in error. The state of the recurrence is
defined by the number of parameters, so it will consist of one number.
Fibonacci needs the last two numbers.
The code doesn't fail because recurrence uses modulus with all indices,
which means a[n-1] and a[n-2] will refer to the same (and only) element
in the recurrence state.
It would be be possible to detect this at run time, but it would slow
things down a bit.
Andrei
Re: D Recurrences
Ben Grabham wrote: > Also, is there a takeWhile function? > I can't find one in the documents... Not yet, but hopefully there will be: http://d.puremagic.com/issues/show_bug.cgi?id=4535
Re: D Recurrences
On 6/9/11 10:32 AM, Ben Grabham wrote:
On 09/06/11 16:19, Ben Grabham wrote:
Hey,
Shouldn't both these programs output the fibonnacci numbers? Only the
first one does.
import std.range;
import std.stdio;
int main() {
auto a = recurrence!("a[n-1] + a[n-2]")(0,1);
int i = 0;
foreach(int n; a) {
if(i++ > 20) break;
writefln("%d", n);
}
return 0;
}
import std.range;
import std.stdio;
int main() {
auto a = recurrence!("a[n-1] + (n < 2 ? 0 : a[n-2])")(1);
int i = 0;
foreach(int n; a) {
if(i++ > 20) break;
writefln("%d", n);
}
return 0;
}
Also, is there a takeWhile function?
I can't find one in the documents...
until?
Andrei
Re: D Recurrences
On 6/9/11 10:42 AM, Timon Gehr wrote: Ben Grabham wrote: Also, is there a takeWhile function? I can't find one in the documents... Not yet, but hopefully there will be: http://d.puremagic.com/issues/show_bug.cgi?id=4535 I think what's unclear is that until() has an overload that takes only the predicate and the range. There's no example for that, so the definition kinda gets lost in the noise. // scan range up until the first zero auto a = until!"a == 0"(range); Andrei
Re: D Recurrences
> On 6/9/11 10:32 AM, Ben Grabham wrote:
>> On 09/06/11 16:19, Ben Grabham wrote:
>>> Hey,
>>>
>>> Shouldn't both these programs output the fibonnacci numbers? Only the
>>> first one does.
>>>
>>> import std.range;
>>> import std.stdio;
>>> int main() {
>>> auto a = recurrence!("a[n-1] + a[n-2]")(0,1);
>>> int i = 0;
>>> foreach(int n; a) {
>>> if(i++ > 20) break;
>>> writefln("%d", n);
>>> }
>>> return 0;
>>> }
>>>
>>>
>>>
>>> import std.range;
>>> import std.stdio;
>>> int main() {
>>> auto a = recurrence!("a[n-1] + (n < 2 ? 0 : a[n-2])")(1);
>>> int i = 0;
>>> foreach(int n; a) {
>>> if(i++ > 20) break;
>>> writefln("%d", n);
>>> }
>>> return 0;
>>> }
>>
>> Also, is there a takeWhile function?
>> I can't find one in the documents...
>
> until?
>
> Andrei
until is not generic enough. It requires you to provide a dummy parameter if you
want to use an unary predicate. And you will have to reverse the predicate:
Thinking "while" is more convenient than thinking "until". Phobos should
definitely get a takeWhile function.
Timon
Re: D Recurrences
Andrei Alexandrescu wrote: > On 6/9/11 10:42 AM, Timon Gehr wrote: >> Ben Grabham wrote: >>> Also, is there a takeWhile function? >>> I can't find one in the documents... >> >> Not yet, but hopefully there will be: >> http://d.puremagic.com/issues/show_bug.cgi?id=4535 > > I think what's unclear is that until() has an overload that takes only > the predicate and the range. There's no example for that, so the > definition kinda gets lost in the noise. > > // scan range up until the first zero > auto a = until!"a == 0"(range); > > > Andrei Oh, I did not know that. That makes things quite a bit better. Still, takeWhile > until. Timon
Phobos consolidated documentation
Hello, I recently added the paraphernalia necessary for a one-file build of the entire Phobos documentation. The system consists of a header template followed by each individual module's documentation in turn followed by a footer template. The documentation is generated using a specialized std.ddoc. See the target html_consolidated in posix.mak: https://github.com/D-Programming-Language/phobos/blob/master/posix.mak#L327 The result: http://d-programming-language.org/phobos-prerelease/std_consolidated.html This can be of course improved in any number of ways, with at least two targets in mind: 1. E-book for kindle etc. In that case probably the navigation means should be adjusted a bit. 2. Printing. In that case navigation becomes irrelevant altogether. If anyone would like to add some html magic, have at it. I'm looking forward to seeing related pull requests! Thanks, Andrei
Re: Instantiating Templates Structs with defaults parameter
d coder: > It would be convenient if I am allowed to use Foo as a type without passing > parameters (with parameterized functions that is the default behavior). I > want to understand if not being able to instantiate Foo with default > parameters is a bug in DMD? Otherwise If it is not allowed in D2, I want to > know why such a limitation is there. I think here DMD is working as intended, and I think this design is correc. This behaviour comes from uniformity: the ! (bang) is always required to instantiate a generic/struct/class/enum template. It's not required for function templates if the types can be inferred. Bye, bearophile
Re: D Recurrences
Ben Grabham:
> import std.range;
> import std.stdio;
> int main() {
> auto a = recurrence!("a[n-1] + a[n-2]")(0,1);
> int i = 0;
> foreach(int n; a) {
> if(i++ > 20) break;
> writefln("%d", n);
> }
> return 0;
> }
This program does something similar to yours (but it doesn't print newlines):
import std.stdio, std.range;
void main() {
auto fib = recurrence!q{ a[n-1] + a[n-2] }(0, 1);
writeln(take(fib, 21));
}
Bye,
bearophile
Re: Instantiating Templates Structs with defaults parameter
On 6/9/11 10:04 AM, d coder wrote:
I don't know whether this should compile but there is a simple work
around:
alias Foo!() Bar;
and then
Bar bar;
works as expected.
Does it help?
Actually it does not. Actually I am trying to create a DESL. For me this
Foo Bar stuff kind of becomes user interface.
Regards
- Puneet
One simple issue is this:
template whatevs(T...) { ... }
whatevs!Foo; // did you mean to pass Foo or Foo!()? Both are legit!
Andrei
Re: D Recurrences
On 09/06/11 17:57, bearophile wrote:
Ben Grabham:
import std.range;
import std.stdio;
int main() {
auto a = recurrence!("a[n-1] + a[n-2]")(0,1);
int i = 0;
foreach(int n; a) {
if(i++> 20) break;
writefln("%d", n);
}
return 0;
}
This program does something similar to yours (but it doesn't print newlines):
import std.stdio, std.range;
void main() {
auto fib = recurrence!q{ a[n-1] + a[n-2] }(0, 1);
writeln(take(fib, 21));
}
Bye,
bearophile
Yeah, thanks
I just wanted to post a bit of code which went wrong :P
Didn't look for optimisations.
Also, how come recurrence isn't properly lazy?
If I define a recurrence and iterate over it twice with foreach, it
takes the same amount of time due to the stack size being set. Is there
a way of defining a lazy list that stores the results when calculated?
Thanks,
Nebster
Re: D Recurrences
On Thu, 09 Jun 2011 13:06:54 -0400, Ben Grabham
wrote:
On 09/06/11 17:57, bearophile wrote:
Ben Grabham:
import std.range;
import std.stdio;
int main() {
auto a = recurrence!("a[n-1] + a[n-2]")(0,1);
int i = 0;
foreach(int n; a) {
if(i++> 20) break;
writefln("%d", n);
}
return 0;
}
This program does something similar to yours (but it doesn't print
newlines):
import std.stdio, std.range;
void main() {
auto fib = recurrence!q{ a[n-1] + a[n-2] }(0, 1);
writeln(take(fib, 21));
}
Bye,
bearophile
Yeah, thanks
I just wanted to post a bit of code which went wrong :P
Didn't look for optimisations.
Also, how come recurrence isn't properly lazy?
If I define a recurrence and iterate over it twice with foreach, it
takes the same amount of time due to the stack size being set. Is there
a way of defining a lazy list that stores the results when calculated?
That's not lazy, that's caching. lazy is 'calculate this when asked'.
You can cache with array:
auto cached = array(take(fib, 21));
// cached now contains the first 21 elements of fib.
-Steve
Re: D Recurrences
On 6/9/11 12:06 PM, Ben Grabham wrote: Also, how come recurrence isn't properly lazy? If I define a recurrence and iterate over it twice with foreach, it takes the same amount of time due to the stack size being set. Is there a way of defining a lazy list that stores the results when calculated? recurrence() is very simple: it starts with the state you pass to it. Then each popFront() overwrites the head of the state (heh) with the calculated value from the existing state. I agree that one could delay any computation until the initial state is exhausted - for example, if the state size is 100, then there's no need to do anything for the first 99 steps. That's far from a common case however as most recurrences have small states and are iterated numerous times. The necessary bookkeeping would slow down that common case a bit. Andrei
Re: D Recurrences
On 09/06/11 18:11, Steven Schveighoffer wrote:
On Thu, 09 Jun 2011 13:06:54 -0400, Ben Grabham
wrote:
On 09/06/11 17:57, bearophile wrote:
Ben Grabham:
import std.range;
import std.stdio;
int main() {
auto a = recurrence!("a[n-1] + a[n-2]")(0,1);
int i = 0;
foreach(int n; a) {
if(i++> 20) break;
writefln("%d", n);
}
return 0;
}
This program does something similar to yours (but it doesn't print
newlines):
import std.stdio, std.range;
void main() {
auto fib = recurrence!q{ a[n-1] + a[n-2] }(0, 1);
writeln(take(fib, 21));
}
Bye,
bearophile
Yeah, thanks
I just wanted to post a bit of code which went wrong :P
Didn't look for optimisations.
Also, how come recurrence isn't properly lazy?
If I define a recurrence and iterate over it twice with foreach, it
takes the same amount of time due to the stack size being set. Is
there a way of defining a lazy list that stores the results when
calculated?
That's not lazy, that's caching. lazy is 'calculate this when asked'.
You can cache with array:
auto cached = array(take(fib, 21));
// cached now contains the first 21 elements of fib.
-Steve
I tried that, but how can I calculate the values only when I want them?
Would I have to store them in a linked list? Since if I know that I will
need 10 prime numbers, it takes my old pc about 4.7 seconds to
calculate them. But can I only calculate them when I need them?
I am running through the recurrence twice so I don't want to calculate
it twice.
This is theoretical so please no answers like put them both in one loop,
etc.
Thanks for all the info so far! I'm learning quite a lot!
Thanks,
Nebster
Re: D Recurrences
On Thu, 09 Jun 2011 13:31:18 -0400, Ben Grabham
wrote:
On 09/06/11 18:11, Steven Schveighoffer wrote:
On Thu, 09 Jun 2011 13:06:54 -0400, Ben Grabham
wrote:
On 09/06/11 17:57, bearophile wrote:
Ben Grabham:
import std.range;
import std.stdio;
int main() {
auto a = recurrence!("a[n-1] + a[n-2]")(0,1);
int i = 0;
foreach(int n; a) {
if(i++> 20) break;
writefln("%d", n);
}
return 0;
}
This program does something similar to yours (but it doesn't print
newlines):
import std.stdio, std.range;
void main() {
auto fib = recurrence!q{ a[n-1] + a[n-2] }(0, 1);
writeln(take(fib, 21));
}
Bye,
bearophile
Yeah, thanks
I just wanted to post a bit of code which went wrong :P
Didn't look for optimisations.
Also, how come recurrence isn't properly lazy?
If I define a recurrence and iterate over it twice with foreach, it
takes the same amount of time due to the stack size being set. Is
there a way of defining a lazy list that stores the results when
calculated?
That's not lazy, that's caching. lazy is 'calculate this when asked'.
You can cache with array:
auto cached = array(take(fib, 21));
// cached now contains the first 21 elements of fib.
-Steve
I tried that, but how can I calculate the values only when I want them?
Would I have to store them in a linked list? Since if I know that I will
need 10 prime numbers, it takes my old pc about 4.7 seconds to
calculate them. But can I only calculate them when I need them?
It's a recurring sequence. As such, each element depends on the previous
n elements. I don't see how you can only calculate them when needed,
unless you want to do some sort of memoization with recursion. recurrence
expects to be traversed in a certain order, it's sort of like dynamic
programming.
The array simply stores all the values needed to an array, so you can
re-access the same values without running through the recurrence.
One thing you could do is using Appender, you can continue a recurrence.
So let's say you need the 5th element of the array:
alias recurrence!q{ a[n-1] + a[n-2] } fib;
Appender!int app;
app.put(take(fib(0, 1), 5));
auto elems = app.data;
auto the5thElement = elems[4];
And now, you need the 10th element:
app.put(take(fib(elems[$-2], elems[$-1]), 10 - elems.length)); // extend
sequence to 10 elements
elems = app.data; // need to re-retrieve the elements
auto the10thElemet = elems[9];
Kind of ugly, but maybe it's close enough to what you want.
I am running through the recurrence twice so I don't want to calculate
it twice.
Yes, you only run through it once, then use the array with the cached data
to retrieve what you want. Accessing the array does not recalculate the
data.
The Appender solution simply keeps a running cache of the data. You could
probably abstract out the 'extending' function. In fact, this whole thing
could be abstracted into a 'cached recurrence' type.
-Steve
Should GC.malloc be considered 'pure'?
Given that the 'new' expression can be used in 'pure', should it be that GC allocation functions like GC.malloc, GC.qalloc and GC.extend (?) be weakly pure also? And should it apply to other managed allocators as well, e.g. the proposed TempAlloc? I'm asking this as one of the specializations of std.conv.toImpl calls GC.malloc, which is one of the 11 causes preventing std.conv.to from being pure, and GC.qalloc and GC.extend (and memcpy and Array.capacity) are used by std.array.appender (of pure range), and appender is also a major reason why std.conv.to is not pure.
Re: D Recurrences
On 09/06/11 18:49, Steven Schveighoffer wrote:
On Thu, 09 Jun 2011 13:31:18 -0400, Ben Grabham
wrote:
On 09/06/11 18:11, Steven Schveighoffer wrote:
On Thu, 09 Jun 2011 13:06:54 -0400, Ben Grabham
wrote:
On 09/06/11 17:57, bearophile wrote:
Ben Grabham:
import std.range;
import std.stdio;
int main() {
auto a = recurrence!("a[n-1] + a[n-2]")(0,1);
int i = 0;
foreach(int n; a) {
if(i++> 20) break;
writefln("%d", n);
}
return 0;
}
This program does something similar to yours (but it doesn't print
newlines):
import std.stdio, std.range;
void main() {
auto fib = recurrence!q{ a[n-1] + a[n-2] }(0, 1);
writeln(take(fib, 21));
}
Bye,
bearophile
Yeah, thanks
I just wanted to post a bit of code which went wrong :P
Didn't look for optimisations.
Also, how come recurrence isn't properly lazy?
If I define a recurrence and iterate over it twice with foreach, it
takes the same amount of time due to the stack size being set. Is
there a way of defining a lazy list that stores the results when
calculated?
That's not lazy, that's caching. lazy is 'calculate this when asked'.
You can cache with array:
auto cached = array(take(fib, 21));
// cached now contains the first 21 elements of fib.
-Steve
I tried that, but how can I calculate the values only when I want
them? Would I have to store them in a linked list? Since if I know
that I will need 10 prime numbers, it takes my old pc about 4.7
seconds to calculate them. But can I only calculate them when I need
them?
It's a recurring sequence. As such, each element depends on the previous
n elements. I don't see how you can only calculate them when needed,
unless you want to do some sort of memoization with recursion.
recurrence expects to be traversed in a certain order, it's sort of like
dynamic programming.
The array simply stores all the values needed to an array, so you can
re-access the same values without running through the recurrence.
One thing you could do is using Appender, you can continue a recurrence.
So let's say you need the 5th element of the array:
alias recurrence!q{ a[n-1] + a[n-2] } fib;
Appender!int app;
app.put(take(fib(0, 1), 5));
auto elems = app.data;
auto the5thElement = elems[4];
And now, you need the 10th element:
app.put(take(fib(elems[$-2], elems[$-1]), 10 - elems.length)); // extend
sequence to 10 elements
elems = app.data; // need to re-retrieve the elements
auto the10thElemet = elems[9];
Kind of ugly, but maybe it's close enough to what you want.
I am running through the recurrence twice so I don't want to calculate
it twice.
Yes, you only run through it once, then use the array with the cached
data to retrieve what you want. Accessing the array does not recalculate
the data.
The Appender solution simply keeps a running cache of the data. You
could probably abstract out the 'extending' function. In fact, this
whole thing could be abstracted into a 'cached recurrence' type.
-Steve
Thanks, that should do the trick!
At the moment I was using auto elems = array(chain(elems, take(primes -
elems.length))); or something similar to that
Also, when using a foreach, is there a special syntax that says include
the last number?
As an example, if I want to loop from -n to +n, I have to do foreach(i;
-n..n+1)
Thanks,
Nebster
Re: Should GC.malloc be considered 'pure'?
On Thu, 09 Jun 2011 13:51:31 -0400, KennyTM~ wrote: Given that the 'new' expression can be used in 'pure', should it be that GC allocation functions like GC.malloc, GC.qalloc and GC.extend (?) be weakly pure also? Yes. But one of the possible issues here: weak purity is determined by the type of the parameters. GC.malloc only takes non-reference types, so marking it as pure might make the compiler actually think these are strong-pure. Don? Any ideas here? I'm thinking we might need an compiler pragma. This would be extremely seldom used. And should it apply to other managed allocators as well, e.g. the proposed TempAlloc? I would say yes, but I think David should have the final say. Definitely, TempAlloc cannot be pure unless GC.malloc and C's malloc are pure, since those are marked that way. I'm asking this as one of the specializations of std.conv.toImpl calls GC.malloc, which is one of the 11 causes preventing std.conv.to from being pure, and GC.qalloc and GC.extend (and memcpy and Array.capacity) are used by std.array.appender (of pure range), and appender is also a major reason why std.conv.to is not pure. I think Appender should also be pure. -Steve
Re: Best article vote tally - WE HAVE TWO WINNERS!
On 09/06/2011 15:13, Steven Schveighoffer wrote: Now you can vote in the next one :) So there is going to be a next one? Maybe next time I won't pull the short straw! :< Congratulations anyway, to Dave as well, your articles were both great! -- Robert http://octarineparrot.com/
Re: D Recurrences
On Thu, 09 Jun 2011 14:02:47 -0400, Ben Grabham
wrote:
Also, when using a foreach, is there a special syntax that says include
the last number?
As an example, if I want to loop from -n to +n, I have to do foreach(i;
-n..n+1)
No. Almost all ranges in D are open interval on the right (don't include
the right element).
There are some corner cases where this can be a problem, like if you
wanted to iterate all the possible ubyte values, you have to do funky
stuff like:
foreach(uint _tmp; ubyte.min..ubyte.max + 1) { auto ub = cast(ubyte)_tmp;
... }
-Steve
Re: Best article vote tally - WE HAVE TWO WINNERS!
On Thu, 09 Jun 2011 14:03:14 -0400, Robert Clipsham wrote: On 09/06/2011 15:13, Steven Schveighoffer wrote: Now you can vote in the next one :) So there is going to be a next one? Maybe next time I won't pull the short straw! :< Congratulations anyway, to Dave as well, your articles were both great! Thanks! To be one vote away is not too bad either! I think all the articles were very good. I told myself on tuesday, no matter what happened, I would be glad that I pushed myself to write an article that helped people. I definitely learned from everyone's articles. It actually makes me want to write more articles... BTW, I debated heavily whether to vote for yours or David's, it really was tough. One vote for you instead of him and the fortunes change dramatically! I'm sure there were some other people who had trouble deciding between my article and someone else's also. It's crazy how close it was. -Steve
Re: Best article vote tally - WE HAVE TWO WINNERS!
On 2011-06-09 11:03, Robert Clipsham wrote: > On 09/06/2011 15:13, Steven Schveighoffer wrote: > > Now you can vote in the next one :) > > So there is going to be a next one? Maybe next time I won't pull the > short straw! :< Short straw? At least yours got some votes! Mine got none. ;) > Congratulations anyway, to Dave as well, your articles were both great! Yes. All of the articles are definitely solid contributions to the D community. I even learned from Steve's article, when I would have thought that I would have known everything in the topic he covered. - Jonathan M Davis
Re: D Recurrences
I never understood why it's called "open" interval. What does it 'open'?
Re: D Recurrences
On 09/06/11 19:45, Andrej Mitrovic wrote: I never understood why it's called "open" interval. What does it 'open'? Don't know the answer to that one, just know it's always been called a open interval when both endpoints aren't included. D's foreach loops are half-closed intervals. Oh well, that's a shame. I ended up writing a lazy cached list and filter implementation anyway :) It may use more memory but it's worth it for me! Thanks for all the help! Nebster
Re: Best article vote tally - WE HAVE TWO WINNERS!
On 6/9/2011 11:26 AM, Jonathan M Davis wrote: At least yours got some votes! Mine got none. ;) I wouldn't worry about that. Consider the Olympics, where the difference between the winners and the rest is, frankly, microscopic. The contest is devised to exaggerate the tiniest of differences. I think all the articles were great!
Re: D Recurrences
On 09/06/11 19:54, Ben Grabham wrote: On 09/06/11 19:45, Andrej Mitrovic wrote: I never understood why it's called "open" interval. What does it 'open'? Don't know the answer to that one, just know it's always been called a open interval when both endpoints aren't included. D's foreach loops are half-closed intervals. Oh well, that's a shame. I ended up writing a lazy cached list and filter implementation anyway :) It may use more memory but it's worth it for me! Thanks for all the help! Nebster Oh, I do have one question though, How does the save property work? I can't seem to be able to return an integer (index) rather than the whole object. How can I do it?
Re: UFCS idea
On Thu, Jun 9, 2011 at 4:29 AM, Kagamin wrote: > Andrew Wiley Wrote: > > > celebrated that we had them too, then stopped. The result is that we're > > throwing around @ as an excuse for language keywords and boasting about > how > > we have annotations when, by the definition of any other language, we > simply > > don't. > > By "any other language" you must mean C# :) > And Java/Scala.
Re: Best article vote tally - WE HAVE TWO WINNERS!
On 6/9/2011 11:03 AM, Robert Clipsham wrote: So there is going to be a next one? Yes, maybe in 6 months or so. I'm very happy with how this one turned out. But next time we need to devise a tie-breaking rule. Any suggestions? A runoff? BTW, there's nothing in the rules preventing an author from tooting his own horn and doing a bit of marketing of their article(s) for votes!
Re: D Recurrences
On Thu, 09 Jun 2011 14:45:49 -0400, Andrej Mitrovic wrote: I never understood why it's called "open" interval. What does it 'open'? Look at the terminology section of http://en.wikipedia.org/wiki/Interval_(mathematics) No clue as to the "why" :) -Steve
Re: D Recurrences
On 6/9/11 8:45 PM, Andrej Mitrovic wrote: I never understood why it's called "open" interval. What does it 'open'? I suppose because, in the topological sense, an open set does not include its boundary, while a closed set does. No boundary <=> open seems quite intuitive to me… David
Re: UFCS idea
On Thu, Jun 9, 2011 at 1:32 AM, Jonathan M Davis wrote: > On 2011-06-09 01:15, Andrew Wiley wrote: > > On Thu, Jun 9, 2011 at 12:46 AM, Jonathan M Davis > wrote: > > > On 2011-06-09 00:20, Andrew Wiley wrote: > > > > On Wed, Jun 8, 2011 at 12:41 PM, Alex_Dovhal > > > > > > wrote: > > > > > There have been several topics discussing UFCS recently. So here is > > > > > one more) > > > > > One idea about UFCS - mark UFCS argument with @, @_, or _ symbol, > > > > > e.g. you have some function: > > > > > void func(Type1 p1, Type2 p2); > > > > > > > > > > and later call it: > > > > > fucn(a, b); //or > > > > > a.func(@_, b); //or > > > > > b.func(a, @_); > > > > > > > > > > This way Timon Gehr's example: > > > > >take(10,stride(2,cycle([3,2,5,3]))); > > > > >[3,2,5,3].cycle().stride(2).take(10); > > > > > > > > > > would be written as this: > > > > >[3,2,5,3].cycle(@_).stride(2, @_).take(10, @_); > > > > > > > > > > Which is a little longer. On the other side this way benefits from: > > > > > * UFCS is directly seen by both the programmer and compiler; > > > > > * UFCS doesn't mix with member call syntax; > > > > > * UFCS can be used for any type and for any argument, e.g. > > > > > > > > > >a.func(@, b) or b.func(a, @); > > > > > > > > > > * UFCS can be used for more than one argument: a.func(@_, @_~[1]); > > > > > > > > > > What do you think? > > > > > > > > I find it funny that @ was initially adopted for annotations, to be > > > > used similar to Java and Scala. I come from that world, and one of > the > > > > rules > > > > > > for > > > > > > > annotations is that they cannot directly alter the code the compiler > > > > outputs. You can add plugins to the Java compiler that use > annotations > > > > to modify the AST before it's compiled, and you can use annotations > > > > for runtime bytecode generation or interpret them using reflection, > > > > but if > > > > > > you > > > > > > > take unannotated code and annotated code and compile it (without > > > > altering the compiler), the generated code will not change. > > > > The idea was to make them a part of the language composed entirely of > > > > metadata (some of which was enforced to be correct by the compiler) > > > > that could be completely ignored if the programmer didn't want to use > > > > it. Now that D has taken up this syntax, we've done almost the > > > > opposite. @ is mostly used in situations where it changes the > compiled > > > > code, changes the existing language, and is in no way optional. We > > > > don't really support > > > > > > user > > > > > > > defined metadata, and we can't use what annotations we have as > metadata > > > > because only the compiler can actually use it. Most of the uses I've > > > > seen seem to be a way to cram more keywords into the language without > > > > adding more keywords. > > > > I've been holding in this sort of rant for a while, but in summary, > my > > > > response is that unless the desired use for @ was defined radically > > > > differently by D when it was adopted (and, as far as I can tell, it > > > > wasn't), seeing another abuse of it just makes me feel slightly sick > > > > inside. > > > > > > As it is, user-defined attributes can be added later using the @ > syntax. > > > True, > > > all of the current uses of @ are for where we decided to save a > keyword, > > > but > > > that doesn't stop user-defined attributes from using the syntax later. > It > > > just > > > means that those that are currently defined will always be special. > > > > This is the difference in philosophy at the core of my general > unhappiness. > > When Java officially added annotations, they were designed and built to > be > > used for user-defined metadata. We added "Property" to the grammar, > > celebrated that we had them too, then stopped. The result is that we're > > throwing around @ as an excuse for language keywords and boasting about > how > > we have annotations when, by the definition of any other language, we > > simply don't. > > I guess the best answer from where I'm standing is to start throwing > around > > possible syntaxes for annotation declarations and references to them in > > compile-time reflection. I just really hope this gets in to D2, so we > > aren't permanently stuck with "fake annotations." > > I don't really see anything wrong with leaving the current @ attributes as > they are and then just using @ for user-defined attributes as well. There > will > just be a set of attribute names which are reserved by the compiler. All > that > using a different syntax for user-defined attributes would buy you would be > that you could use the attribute names that the compiler has reserved - > safe, > trusted, system, and property. And that isn't exactly a huge gain. We might > as > well just use @ for user-defined attributes as well. > My point wasn't that the syntax should be different (it should definitely be the same), my point was that we stopped short of fully implementing
Re: D Recurrences
Steve Schveighoffer wrote: > On Thu, 09 Jun 2011 14:45:49 -0400, Andrej Mitrovic > wrote: > > > I never understood why it's called "open" interval. What does it 'open'? > > Look at the terminology section of > http://en.wikipedia.org/wiki/Interval_(mathematics) > > No clue as to the "why" :) > > -Steve Actually it does not make too much sense to use the terms open or closed on integer intervals in a strict mathematical sense. If your universe is the integers, all subsets of the integers are neither open nor closed, with the exception of the empty set and the set of all integers, which are both open and closed. :o) Timon
Re: D Recurrences
On 2011-06-09 11:59, Ben Grabham wrote: > On 09/06/11 19:54, Ben Grabham wrote: > > On 09/06/11 19:45, Andrej Mitrovic wrote: > >> I never understood why it's called "open" interval. What does it 'open'? > > > > Don't know the answer to that one, just know it's always been called a > > open interval when both endpoints aren't included. D's foreach loops are > > half-closed intervals. > > > > Oh well, that's a shame. > > > > I ended up writing a lazy cached list and filter implementation anyway :) > > > > It may use more memory but it's worth it for me! > > > > Thanks for all the help! > > Nebster > > Oh, I do have one question though, > > How does the save property work? I can't seem to be able to return an > integer (index) rather than the whole object. How can I do it? The save property of a forward range returns a copy of that range. In most cases, since ranges are generally restructs, it just returns the range. You use it when you want to save the original range and still be able pop elements off. auto orig = range.save; //pop off as many elements from range as I want. //orig still has all of its elements The elements aren't copied however, just the range. Regardless, it has nothing to do with returning an element from a range, so I don't understand your question about returning an index rather than a whole object. Ranges don't really use indicies. indexOf will tell you the index of a particular element, and you can increment a counter every time you pop off an element if you want to know how many elements you've consumed, but once an element has been popped off, it's not part of that range anymore (though it could be part of a saved range), so that could seriously affect by what you mean by index, depending on what you're doing. - Jonathan M Davis
Re: Best article vote tally - WE HAVE TWO WINNERS!
On 2011-06-09 11:58, Walter Bright wrote: > On 6/9/2011 11:26 AM, Jonathan M Davis wrote: > > At least yours got some votes! Mine got none. ;) > > I wouldn't worry about that. Consider the Olympics, where the difference > between the winners and the rest is, frankly, microscopic. The contest is > devised to exaggerate the tiniest of differences. > > I think all the articles were great! Oh, I don't really mind. It doesn't mean that my article was bad, just that no one who voted didn't think that it was the best. It doesn't even mean that mine would win the "worst article" vote if we were to be mean enough to have such a vote. It just means that no one thought that my article was the best. I didn't really write my article for the contest anyway, so it's not a big deal. I wrote the article because it clearly needed to be written, and getting it in the contest was just a nice bonus. - Jonathan M Davis
Re: Best article vote tally - WE HAVE TWO WINNERS!
On 09/06/2011 20:02, Walter Bright wrote: On 6/9/2011 11:03 AM, Robert Clipsham wrote: So there is going to be a next one? Yes, maybe in 6 months or so. I'm very happy with how this one turned out. Excellent! I really enjoyed writing my article, 'twas great fun. I plan on writing more, the major set backs for me are lack of ideas and lack of time (though if I find something interesting time seems to manifest itself anyway). But next time we need to devise a tie-breaking rule. Any suggestions? A runoff? This could be difficult - if I'd had one more vote we'd have had a three way tie, and I doubt another round of voting would have made a difference. My suggestion would be something more imaginative to tie break. We can't do rock paper scissors over the internet or use a random number generator without people complaining about it being fixed, but how about a puzzle of some sort? Obviously it should be accessible to all (we could get a fantastic article from someone who's not from an academic background that would struggle with say, an Euler problem). Perhaps who can do X in the coolest possible way using D. Then that could be voted on. Alternatively, there could be another round of articles (probably too time consuming) or opening voting up to other programming communities. I had some other ideas, but I've forgotten them. BTW, there's nothing in the rules preventing an author from tooting his own horn and doing a bit of marketing of their article(s) for votes! Who says we didn't do that? :D The D community is far too moral though, when it's the last 30 minutes of the competition everyone claims they don't have enough time to read the articles, they refuse to vote blindly. Not that I'd know of course! -- Robert http://octarineparrot.com/
Re: D Recurrences
Timon Gehr wrote: > Steve Schveighoffer wrote: >> On Thu, 09 Jun 2011 14:45:49 -0400, Andrej Mitrovic >> wrote: >> >> > I never understood why it's called "open" interval. What does it 'open'? >> >> Look at the terminology section of >> http://en.wikipedia.org/wiki/Interval_(mathematics) >> >> No clue as to the "why" :) >> >> -Steve > > Actually it does not make too much sense to use the terms open or closed on > integer intervals in a strict mathematical sense. If your universe is the > integers, all subsets of the integers are neither open nor closed, with the > exception of the empty set and the set of all integers, which are both open > > and > closed. :o) I'm sorry, this was misinformation. Actually *all* subsets are both open and closed. Timon
Re: UFCS idea
On 2011-06-09 12:01, Andrew Wiley wrote: > On Thu, Jun 9, 2011 at 1:32 AM, Jonathan M Davis wrote: > > On 2011-06-09 01:15, Andrew Wiley wrote: > > > On Thu, Jun 9, 2011 at 12:46 AM, Jonathan M Davis > > > > wrote: > > > > On 2011-06-09 00:20, Andrew Wiley wrote: > > > > > On Wed, Jun 8, 2011 at 12:41 PM, Alex_Dovhal > > > > > > > > > > > > > wrote: > > > > > > There have been several topics discussing UFCS recently. So here > > > > > > is one more) > > > > > > One idea about UFCS - mark UFCS argument with @, @_, or _ symbol, > > > > > > e.g. you have some function: > > > > > > void func(Type1 p1, Type2 p2); > > > > > > > > > > > > and later call it: > > > > > > fucn(a, b); //or > > > > > > a.func(@_, b); //or > > > > > > b.func(a, @_); > > > > > > > > > > > > This way Timon Gehr's example: > > > > > >take(10,stride(2,cycle([3,2,5,3]))); > > > > > >[3,2,5,3].cycle().stride(2).take(10); > > > > > > > > > > > > would be written as this: > > > > > >[3,2,5,3].cycle(@_).stride(2, @_).take(10, @_); > > > > > > > > > > > > Which is a little longer. On the other side this way benefits from: > > > > > > * UFCS is directly seen by both the programmer and compiler; > > > > > > * UFCS doesn't mix with member call syntax; > > > > > > * UFCS can be used for any type and for any argument, e.g. > > > > > > > > > > > >a.func(@, b) or b.func(a, @); > > > > > > > > > > > > * UFCS can be used for more than one argument: a.func(@_, > > > > > > @_~[1]); > > > > > > > > > > > > What do you think? > > > > > > > > > > I find it funny that @ was initially adopted for annotations, to be > > > > > used similar to Java and Scala. I come from that world, and one of > > > > the > > > > > > > rules > > > > > > > > for > > > > > > > > > annotations is that they cannot directly alter the code the > > > > > compiler outputs. You can add plugins to the Java compiler that > > > > > use > > > > annotations > > > > > > > to modify the AST before it's compiled, and you can use annotations > > > > > for runtime bytecode generation or interpret them using reflection, > > > > > but if > > > > > > > > you > > > > > > > > > take unannotated code and annotated code and compile it (without > > > > > altering the compiler), the generated code will not change. > > > > > The idea was to make them a part of the language composed entirely > > > > > of metadata (some of which was enforced to be correct by the > > > > > compiler) that could be completely ignored if the programmer > > > > > didn't want to use it. Now that D has taken up this syntax, we've > > > > > done almost the opposite. @ is mostly used in situations where it > > > > > changes the > > > > compiled > > > > > > > code, changes the existing language, and is in no way optional. We > > > > > don't really support > > > > > > > > user > > > > > > > > > defined metadata, and we can't use what annotations we have as > > > > metadata > > > > > > > because only the compiler can actually use it. Most of the uses > > > > > I've seen seem to be a way to cram more keywords into the language > > > > > without adding more keywords. > > > > > I've been holding in this sort of rant for a while, but in summary, > > > > my > > > > > > > response is that unless the desired use for @ was defined radically > > > > > differently by D when it was adopted (and, as far as I can tell, it > > > > > wasn't), seeing another abuse of it just makes me feel slightly > > > > > sick inside. > > > > > > > > As it is, user-defined attributes can be added later using the @ > > > > syntax. > > > > > > True, > > > > all of the current uses of @ are for where we decided to save a > > > > keyword, > > > > > > but > > > > that doesn't stop user-defined attributes from using the syntax > > > > later. > > > > It > > > > > > just > > > > means that those that are currently defined will always be special. > > > > > > This is the difference in philosophy at the core of my general > > > > unhappiness. > > > > > When Java officially added annotations, they were designed and built to > > > > be > > > > > used for user-defined metadata. We added "Property" to the grammar, > > > celebrated that we had them too, then stopped. The result is that we're > > > throwing around @ as an excuse for language keywords and boasting about > > > > how > > > > > we have annotations when, by the definition of any other language, we > > > simply don't. > > > I guess the best answer from where I'm standing is to start throwing > > > > around > > > > > possible syntaxes for annotation declarations and references to them in > > > compile-time reflection. I just really hope this gets in to D2, so we > > > aren't permanently stuck with "fake annotations." > > > > I don't really see anything wrong with leaving the current @ attributes > > as they are and then just using @ for user-defined attributes as well. > > There will > > just be a set of attribute names which are reserved by the compiler. A
Re: Best article vote tally - WE HAVE TWO WINNERS!
On 09/06/2011 19:26, Jonathan M Davis wrote: On 2011-06-09 11:03, Robert Clipsham wrote: On 09/06/2011 15:13, Steven Schveighoffer wrote: Now you can vote in the next one :) So there is going to be a next one? Maybe next time I won't pull the short straw! :< Short straw? At least yours got some votes! Mine got none. ;) Maybe it wasn't the shortest straw then. Your article was great, I guess it didn't apply to a lot of people though. Congratulations anyway, to Dave as well, your articles were both great! Yes. All of the articles are definitely solid contributions to the D community. I even learned from Steve's article, when I would have thought that I would have known everything in the topic he covered. Indeed - I'll be giving it another read through at some point to check I got it all! - Jonathan M Davis -- Robert http://octarineparrot.com/
Re: Best article vote tally - WE HAVE TWO WINNERS!
On Thu, 09 Jun 2011 15:02:08 -0400, Walter Bright wrote: On 6/9/2011 11:03 AM, Robert Clipsham wrote: So there is going to be a next one? Yes, maybe in 6 months or so. I'm very happy with how this one turned out. But next time we need to devise a tie-breaking rule. Any suggestions? A runoff? We're all developers here, I think people might be open to an instant runoff: http://en.wikipedia.org/wiki/Instant-runoff_voting Essentially, you rank the articles 1 to x, and then the algorithm figures out the winner. It's still possible to have a tie, but unlikely. I think for the next time, someone should write a newsgroup-to-vote program that automatically counts the votes (must be in D of course!) BTW, there's nothing in the rules preventing an author from tooting his own horn and doing a bit of marketing of their article(s) for votes! We're developers, not politicians :) If you allow this, then we'll have to start creating youtube ads showing the other articles' past records of infidelity and such, and it just turns ugly. -Steve
Re: Best article vote tally
On 08/06/2011 05:54, Walter Bright wrote: Looks like we have a tie. Darn it. I don't really want to do Solomon's solution! A tad belated, but I'd like to thank everyone who voted for my article! I really enjoyed writing it, I'm glad you enjoyed reading it. -- Robert http://octarineparrot.com/
Re: Best article vote tally - WE HAVE TWO WINNERS!
On 09/06/2011 20:21, Steven Schveighoffer wrote: On Thu, 09 Jun 2011 15:02:08 -0400, Walter Bright wrote: On 6/9/2011 11:03 AM, Robert Clipsham wrote: So there is going to be a next one? Yes, maybe in 6 months or so. I'm very happy with how this one turned out. But next time we need to devise a tie-breaking rule. Any suggestions? A runoff? We're all developers here, I think people might be open to an instant runoff: http://en.wikipedia.org/wiki/Instant-runoff_voting Essentially, you rank the articles 1 to x, and then the algorithm figures out the winner. It's still possible to have a tie, but unlikely. I thought about mentioning this, but decided against it. I believe FPTP is the best way to vote for this kind of competition. I think for the next time, someone should write a newsgroup-to-vote program that automatically counts the votes (must be in D of course!) Of course, then that one person who doesn't format their vote quite right loses out... BTW, there's nothing in the rules preventing an author from tooting his own horn and doing a bit of marketing of their article(s) for votes! We're developers, not politicians :) If you allow this, then we'll have to start creating youtube ads showing the other articles' past records of infidelity and such, and it just turns ugly. Given the rule that voters must have used their handle here before, that's not going to happen. I won't comment further to avoid ranting. -Steve -- Robert http://octarineparrot.com/
Re: Should GC.malloc be considered 'pure'?
Steven Schveighoffer: > Don? Any ideas here? I'm thinking we might need an compiler pragma. > This would be extremely seldom used. We're back to some concept of referential transparency of pointers/reference types, that has produced a tepid response... :-) Bye, bearophile
Re: Best article vote tally - WE HAVE TWO WINNERS!
Am 09.06.2011 21:18, schrieb Jonathan M Davis: > On 2011-06-09 11:58, Walter Bright wrote: >> On 6/9/2011 11:26 AM, Jonathan M Davis wrote: >>> At least yours got some votes! Mine got none. ;) >> >> I wouldn't worry about that. Consider the Olympics, where the difference >> between the winners and the rest is, frankly, microscopic. The contest is >> devised to exaggerate the tiniest of differences. >> >> I think all the articles were great! > > Oh, I don't really mind. It doesn't mean that my article was bad, just that > no > one who voted didn't think that it was the best. It doesn't even mean that > mine would win the "worst article" vote if we were to be mean enough to have > such a vote. It just means that no one thought that my article was the best. > > I didn't really write my article for the contest anyway, so it's not a big > deal. I wrote the article because it clearly needed to be written, and > getting > it in the contest was just a nice bonus. > > - Jonathan M Davis It is a great article, pretty informative and certainly a big help for anyone wanting to mess with time-related stuff in D. But I guess the topic is just not as sexy as parallelism or efficiency (slices are also efficiency-related, besides providing nice syntax-sugar for array operations). As you said, that article needed to be written and it's a valuable addition to std.datetime's documentation. Cheers, - Daniel
Re: Best article vote tally - WE HAVE TWO WINNERS!
Am 09.06.2011 21:02, schrieb Walter Bright:
> On 6/9/2011 11:03 AM, Robert Clipsham wrote:
>> So there is going to be a next one?
>
> Yes, maybe in 6 months or so. I'm very happy with how this one turned out.
>
> But next time we need to devise a tie-breaking rule. Any suggestions? A
> runoff?
>
> BTW, there's nothing in the rules preventing an author from tooting his
> own horn and doing a bit of marketing of their article(s) for votes!
"If I win I'll implement $great_feature_everyone_wants" ;-)
("If I win I port a D compiler to ARM/iOS" would really make sense, when
the price is an iPad - it's kind of ironic anyway that the price is a
kind of computer that isn't supported by D)
Cheers,
- Daniel
Re: Should GC.malloc be considered 'pure'?
On 6/9/11 12:51 PM, KennyTM~ wrote: Given that the 'new' expression can be used in 'pure', should it be that GC allocation functions like GC.malloc, GC.qalloc and GC.extend (?) be weakly pure also? And should it apply to other managed allocators as well, e.g. the proposed TempAlloc? I'm asking this as one of the specializations of std.conv.toImpl calls GC.malloc, which is one of the 11 causes preventing std.conv.to from being pure, and GC.qalloc and GC.extend (and memcpy and Array.capacity) are used by std.array.appender (of pure range), and appender is also a major reason why std.conv.to is not pure. GC.malloc is not technically pure because its result does not only depend on arguments - it's a fresh value each time. So the compiler can't apply pure reasoning to it. Andrei
Re: Best article vote tally - WE HAVE TWO WINNERS!
On Thu, 09 Jun 2011 15:35:44 -0400, Robert Clipsham wrote: On 09/06/2011 20:21, Steven Schveighoffer wrote: On Thu, 09 Jun 2011 15:02:08 -0400, Walter Bright wrote: On 6/9/2011 11:03 AM, Robert Clipsham wrote: So there is going to be a next one? Yes, maybe in 6 months or so. I'm very happy with how this one turned out. But next time we need to devise a tie-breaking rule. Any suggestions? A runoff? We're all developers here, I think people might be open to an instant runoff: http://en.wikipedia.org/wiki/Instant-runoff_voting Essentially, you rank the articles 1 to x, and then the algorithm figures out the winner. It's still possible to have a tie, but unlikely. I thought about mentioning this, but decided against it. I believe FPTP is the best way to vote for this kind of competition. I wonder if there's some form of instant runoff that only breaks ties. That is, a runoff only occurs between ties, with the people who did not vote for the tied candidates getting their secondary votes counted. I suppose most voting systems are for votes that count in the hundreds of thousands to millions, so there is very little chance of a tie. So this might be unexplored territory... I just am not keen on the idea that someone can vote for candidate A, then when A ties with B, vote for candidate B in the runoff. Instant runoff appeals to me because you have to write down your preferences up front. I think for the next time, someone should write a newsgroup-to-vote program that automatically counts the votes (must be in D of course!) Of course, then that one person who doesn't format their vote quite right loses out... Well, we can make it simple: Mark your preference in this box (1-5): | v [ ] article 1 [ ] article 2 ... Another (really good) option is to use a web-based voting system, which makes things verifiable. You still need something to verify the user has posted to the NG in the past. BTW, there's nothing in the rules preventing an author from tooting his own horn and doing a bit of marketing of their article(s) for votes! We're developers, not politicians :) If you allow this, then we'll have to start creating youtube ads showing the other articles' past records of infidelity and such, and it just turns ugly. Given the rule that voters must have used their handle here before, that's not going to happen. I won't comment further to avoid ranting. I hope you didn't think I was serious, though I don't see how it could be seen that way. If I offended, I'm sorry. -Steve
Re: Should GC.malloc be considered 'pure'?
On Thu, 09 Jun 2011 16:08:33 -0400, Andrei Alexandrescu wrote: On 6/9/11 12:51 PM, KennyTM~ wrote: Given that the 'new' expression can be used in 'pure', should it be that GC allocation functions like GC.malloc, GC.qalloc and GC.extend (?) be weakly pure also? And should it apply to other managed allocators as well, e.g. the proposed TempAlloc? I'm asking this as one of the specializations of std.conv.toImpl calls GC.malloc, which is one of the 11 causes preventing std.conv.to from being pure, and GC.qalloc and GC.extend (and memcpy and Array.capacity) are used by std.array.appender (of pure range), and appender is also a major reason why std.conv.to is not pure. GC.malloc is not technically pure because its result does not only depend on arguments - it's a fresh value each time. So the compiler can't apply pure reasoning to it. It's weak-pure, not strong-pure. weak-pure functions are allowed to return different values for two different runs with the same parameters. Essentially, weak-pure functions cannot have pure reasoning applied to them, *but* they can be called from strong-pure functions. It's not technically even weak-pure because it uses global data. But because memory allocation is so important to any functional programming, it needs to be an exception. -Steve
Re: D Recurrences
On Jun 10, 11 03:20, Timon Gehr wrote: Timon Gehr wrote: Steve Schveighoffer wrote: On Thu, 09 Jun 2011 14:45:49 -0400, Andrej Mitrovic wrote: I never understood why it's called "open" interval. What does it 'open'? Look at the terminology section of http://en.wikipedia.org/wiki/Interval_(mathematics) No clue as to the "why" :) -Steve Actually it does not make too much sense to use the terms open or closed on integer intervals in a strict mathematical sense. If your universe is the integers, all subsets of the integers are neither open nor closed, with the exception of the empty set and the set of all integers, which are both open> and closed. :o) I'm sorry, this was misinformation. Actually *all* subsets are both open and closed. Timon That depends on how you define the topology on Z anyway.
Re: Best article vote tally - WE HAVE TWO WINNERS!
On 06/09/2011 01:21 PM, Steven Schveighoffer wrote: On Thu, 09 Jun 2011 15:02:08 -0400, Walter Bright wrote: On 6/9/2011 11:03 AM, Robert Clipsham wrote: So there is going to be a next one? Yes, maybe in 6 months or so. I'm very happy with how this one turned out. But next time we need to devise a tie-breaking rule. Any suggestions? A runoff? We're all developers here, I think people might be open to an instant runoff: http://en.wikipedia.org/wiki/Instant-runoff_voting Essentially, you rank the articles 1 to x, and then the algorithm figures out the winner. It's still possible to have a tie, but unlikely. I think for the next time, someone should write a newsgroup-to-vote program that automatically counts the votes (must be in D of course!) BTW, there's nothing in the rules preventing an author from tooting his own horn and doing a bit of marketing of their article(s) for votes! We're developers, not politicians :) If you allow this, then we'll have to start creating youtube ads showing the other articles' past records of infidelity and such, and it just turns ugly. -Steve I second the vote for IRV.
Re: Best article vote tally - WE HAVE TWO WINNERS!
A lot of technical groups that do voting use the Schulze method < http://en.wikipedia.org/wiki/Schulze_method>. Similar to IRV but technically better. I'm not sure how easy it is to do in practice. On Thu, Jun 9, 2011 at 3:06 PM, Kai Meyer wrote: > On 06/09/2011 01:21 PM, Steven Schveighoffer wrote: > >> On Thu, 09 Jun 2011 15:02:08 -0400, Walter Bright >> wrote: >> >> On 6/9/2011 11:03 AM, Robert Clipsham wrote: >>> So there is going to be a next one? >>> >>> Yes, maybe in 6 months or so. I'm very happy with how this one turned >>> out. >>> >>> But next time we need to devise a tie-breaking rule. Any suggestions? >>> A runoff? >>> >> >> We're all developers here, I think people might be open to an instant >> runoff: >> >> http://en.wikipedia.org/wiki/Instant-runoff_voting >> >> Essentially, you rank the articles 1 to x, and then the algorithm >> figures out the winner. It's still possible to have a tie, but unlikely. >> >> I think for the next time, someone should write a newsgroup-to-vote >> program that automatically counts the votes (must be in D of course!) >> >> BTW, there's nothing in the rules preventing an author from tooting >>> his own horn and doing a bit of marketing of their article(s) for votes! >>> >> >> We're developers, not politicians :) If you allow this, then we'll have >> to start creating youtube ads showing the other articles' past records >> of infidelity and such, and it just turns ugly. >> >> -Steve >> > > I second the vote for IRV. >
Re: Best article vote tally - WE HAVE TWO WINNERS!
On Thu, 09 Jun 2011 17:27:14 -0400, Brad Anderson wrote: A lot of technical groups that do voting use the Schulze method < http://en.wikipedia.org/wiki/Schulze_method>. Similar to IRV but technically better. I'm not sure how easy it is to do in practice. That looks cool, but we need a proven piece of software to do it :) I'd vote for that method. -Steve
Re: D Recurrences
On 6/9/11, Steven Schveighoffer wrote: > On Thu, 09 Jun 2011 14:45:49 -0400, Andrej Mitrovic > wrote: > >> I never understood why it's called "open" interval. What does it 'open'? > > Look at the terminology section of > http://en.wikipedia.org/wiki/Interval_(mathematics) > > No clue as to the "why" :) > > -Steve > The why is what I'm after. Let me take a look at some definitions of "open" from thefreedictionary (excluding the definitions under the math section): "Carried on in full view" "Spread out; unfolded" "Accessible to all" "Lacking effective regulation" It seems more natural to me to think of open as something that encompasses a larger scope. E.g. when you spread your arms you have a larger area between your hands, not smaller.
Re: D Recurrences
Andrei Mitrovic wrote: > On 6/9/11, Steven Schveighoffer wrote: >> On Thu, 09 Jun 2011 14:45:49 -0400, Andrej Mitrovic >> wrote: >> >>> I never understood why it's called "open" interval. What does it 'open'? >>> >> Look at the terminology section of >> http://en.wikipedia.org/wiki/Interval_(mathematics) >> >> No clue as to the "why" :) >> >> -Steve >> > > The why is what I'm after. > > Let me take a look at some definitions of "open" from > thefreedictionary (excluding the definitions under the math section): > "Carried on in full view" > "Spread out; unfolded" > "Accessible to all" > "Lacking effective regulation" > > It seems more natural to me to think of open as something that > encompasses a larger scope. E.g. when you spread your arms you have a > larger area between your hands, not smaller. I think it is called open, because you can go into any direction from a point within an open set without leaving the set. There are no boundaries. Timon
Re: Should GC.malloc be considered 'pure'?
Andrei: > GC.malloc is not technically pure because its result does not only > depend on arguments - it's a fresh value each time. So the compiler > can't apply pure reasoning to it. So is the ptr field of a dynamic array allocated inside a strongly pure function. Did you miss the discussion I've had here about the @trasparent? The allocation of heap memory can be considered pure if you use the allocated memory as a referentially transparent value (this means it's allowed to be used by reference, but your code is not allowed to read the value of the reference itself, so the future state of the code depends only on the contents of the referenced memory, and not the reference itself. Also, overwriting this reference is kosher still :-) Bye, bearophile
Re: D Recurrences
On Thu, 09 Jun 2011 16:19:23 +0100, Ben Grabham wrote:
> Hey,
>
> Shouldn't both these programs output the fibonnacci numbers? Only the
> first one does.
>
> import std.range;
> import std.stdio;
> int main() {
> auto a = recurrence!("a[n-1] + a[n-2]")(0,1); int i = 0;
> foreach(int n; a) {
> if(i++ > 20) break;
> writefln("%d", n);
> }
> return 0;
> }
>
>
>
> import std.range;
> import std.stdio;
> int main() {
> auto a = recurrence!("a[n-1] + (n < 2 ? 0 : a[n-2])")(1); int i =
0;
> foreach(int n; a) {
> if(i++ > 20) break;
> writefln("%d", n);
> }
> return 0;
> }
For what it's worth, here is a Fibonacci range. (Translated from
D.ershane's "Aralıklar" (Ranges) chapter.)
import std.stdio;
import std.range;
struct FibonacciRange
{
int first = 0;
int second = 1;
enum empty = false;
@property int front() const
{
return first;
}
void popFront()
{
int next = first + second;
first = second;
second = next;
}
FibonacciRange save() const
{
return this;
}
}
void main()
{
writeln(take(FibonacciRange(), 20));
}
Ali
Improving (foreach) ranges
With the introduction of std.parallelism, I've been wondering about the
following:
foreach (i; 0..100)
{
}
For most uses of foreach, you can just wrap the range in parallel(), but
with a foreach range statement you can't do this. Of course iota() could
be used:
foreach (i; parallel(iota(0, 100)))
{
}
But that seems inconsistent. What are people's thoughts on making the
syntax a..b more general, so you can do eg:
void foo(int[]);
foo(0..100);
Although, I seem to recall seeing this conversation elsewhere, let me
know if this is the case.
--
Robert
http://octarineparrot.com/
Re: Best article vote tally - WE HAVE TWO WINNERS!
On 6/9/2011 12:21 PM, Steven Schveighoffer wrote: We're developers, not politicians :) If you allow this, then we'll have to start creating youtube ads showing the other articles' past records of infidelity and such, and it just turns ugly. I only ask that the sexting stay off this n.g.!
Re: Best article vote tally - WE HAVE TWO WINNERS!
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article > On Thu, 09 Jun 2011 17:27:14 -0400, Brad Anderson wrote: > > A lot of technical groups that do voting use the Schulze method < > > http://en.wikipedia.org/wiki/Schulze_method>. Similar to IRV but > > technically better. I'm not sure how easy it is to do in practice. > That looks cool, but we need a proven piece of software to do it :) > I'd vote for that method. > -Steve Looks similar very similar to AV, which doesn't need a piece of software to count (though obviously it helps ;). http://en.wikipedia.org/wiki/Alternative_Vote
Re: Best article vote tally - WE HAVE TWO WINNERS!
On 6/9/2011 12:57 PM, Daniel Gibson wrote:
("If I win I port a D compiler to ARM/iOS" would really make sense, when
the price is an iPad - it's kind of ironic anyway that the price is a
kind of computer that isn't supported by D)
I thought a t-shirt as a prize would be awfully lame!
Re: Best article vote tally - WE HAVE TWO WINNERS!
On 6/10/11 1:36 AM, Iain Buclaw wrote: == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article On Thu, 09 Jun 2011 17:27:14 -0400, Brad Anderson wrote: A lot of technical groups that do voting use the Schulze method< http://en.wikipedia.org/wiki/Schulze_method>. Similar to IRV but technically better. I'm not sure how easy it is to do in practice. That looks cool, but we need a proven piece of software to do it :) I'd vote for that method. -Steve Looks similar very similar to AV, which doesn't need a piece of software to count (though obviously it helps ;). http://en.wikipedia.org/wiki/Alternative_Vote This might also be a nice starting point for further exploring the topic: http://en.wikipedia.org/wiki/Single-winner_voting_system#Comparison_of_single-winner_election_methods David
Re: Best article vote tally - WE HAVE TWO WINNERS!
On 10/06/2011 00:36, Iain Buclaw wrote: == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article On Thu, 09 Jun 2011 17:27:14 -0400, Brad Anderson wrote: A lot of technical groups that do voting use the Schulze method< http://en.wikipedia.org/wiki/Schulze_method>. Similar to IRV but technically better. I'm not sure how easy it is to do in practice. That looks cool, but we need a proven piece of software to do it :) I'd vote for that method. -Steve Looks similar very similar to AV, which doesn't need a piece of software to count (though obviously it helps ;). http://en.wikipedia.org/wiki/Alternative_Vote AV, also known as IRV (see above) :D -- Robert http://octarineparrot.com/
Re: Best article vote tally - WE HAVE TWO WINNERS!
On Thu, 09 Jun 2011 19:35:41 -0400, Walter Bright
wrote:
On 6/9/2011 12:57 PM, Daniel Gibson wrote:
("If I win I port a D compiler to ARM/iOS" would really make sense, when
the price is an iPad - it's kind of ironic anyway that the price is a
kind of computer that isn't supported by D)
I thought a t-shirt as a prize would be awfully lame!
"I wrote this article on D, and all I got was this lousy!T shirt"
-Steve
Re: Best article vote tally - WE HAVE TWO WINNERS!
On 6/9/11 6:40 PM, Steven Schveighoffer wrote:
On Thu, 09 Jun 2011 19:35:41 -0400, Walter Bright
wrote:
On 6/9/2011 12:57 PM, Daniel Gibson wrote:
("If I win I port a D compiler to ARM/iOS" would really make sense, when
the price is an iPad - it's kind of ironic anyway that the price is a
kind of computer that isn't supported by D)
I thought a t-shirt as a prize would be awfully lame!
"I wrote this article on D, and all I got was this lousy!T shirt"
-Steve
Post o' the month.
Andrei
Re: Improving (foreach) ranges
Yeah there was a big discussion about this IIRC. I can't recall the exact link to the topic, sorry.
Re: Best article vote tally - WE HAVE TWO WINNERS!
On 2011-06-09 16:40, Steven Schveighoffer wrote:
> On Thu, 09 Jun 2011 19:35:41 -0400, Walter Bright
>
> wrote:
> > On 6/9/2011 12:57 PM, Daniel Gibson wrote:
> >> ("If I win I port a D compiler to ARM/iOS" would really make sense, when
> >> the price is an iPad - it's kind of ironic anyway that the price is a
> >> kind of computer that isn't supported by D)
> >
> > I thought a t-shirt as a prize would be awfully lame!
>
> "I wrote this article on D, and all I got was this lousy!T shirt"
LOL. Good one. Now I want that t-shirt...
- Jonathan M Davis
Re: Best article vote tally - WE HAVE TWO WINNERS!
Am 10.06.2011 01:35, schrieb Walter Bright:
> On 6/9/2011 12:57 PM, Daniel Gibson wrote:
>> ("If I win I port a D compiler to ARM/iOS" would really make sense, when
>> the price is an iPad - it's kind of ironic anyway that the price is a
>> kind of computer that isn't supported by D)
>
> I thought a t-shirt as a prize would be awfully lame!
Hmm D t-shirts would actually be kind of cool (maybe not as first price
in an article contest but in general).
Ever thought about selling D merchandise (t-shirts, mugs, stuff like that)?
Re: Best article vote tally - WE HAVE TWO WINNERS!
On 10/06/2011 00:56, Daniel Gibson wrote:
Am 10.06.2011 01:35, schrieb Walter Bright:
On 6/9/2011 12:57 PM, Daniel Gibson wrote:
("If I win I port a D compiler to ARM/iOS" would really make sense, when
the price is an iPad - it's kind of ironic anyway that the price is a
kind of computer that isn't supported by D)
I thought a t-shirt as a prize would be awfully lame!
Hmm D t-shirts would actually be kind of cool (maybe not as first price
in an article contest but in general).
Ever thought about selling D merchandise (t-shirts, mugs, stuff like that)?
Not hugely complete, but: http://digitalmars.com/gift/index.html
--
Robert
http://octarineparrot.com/
Re: Best article vote tally - WE HAVE TWO WINNERS!
On 10/06/2011 00:40, Steven Schveighoffer wrote:
On Thu, 09 Jun 2011 19:35:41 -0400, Walter Bright
wrote:
On 6/9/2011 12:57 PM, Daniel Gibson wrote:
("If I win I port a D compiler to ARM/iOS" would really make sense, when
the price is an iPad - it's kind of ironic anyway that the price is a
kind of computer that isn't supported by D)
I thought a t-shirt as a prize would be awfully lame!
"I wrote this article on D, and all I got was this lousy!T shirt"
-Steve
I would happily accept this as my runners up prize.
--
Robert
http://octarineparrot.com/
Re: Best article vote tally - WE HAVE TWO WINNERS!
Am 10.06.2011 02:06, schrieb Robert Clipsham:
> On 10/06/2011 00:56, Daniel Gibson wrote:
>> Am 10.06.2011 01:35, schrieb Walter Bright:
>>> On 6/9/2011 12:57 PM, Daniel Gibson wrote:
("If I win I port a D compiler to ARM/iOS" would really make sense,
when
the price is an iPad - it's kind of ironic anyway that the price is a
kind of computer that isn't supported by D)
>>>
>>> I thought a t-shirt as a prize would be awfully lame!
>>
>> Hmm D t-shirts would actually be kind of cool (maybe not as first price
>> in an article contest but in general).
>> Ever thought about selling D merchandise (t-shirts, mugs, stuff like
>> that)?
>
> Not hugely complete, but: http://digitalmars.com/gift/index.html
>
Cool - where is the link to that page hidden?
Couldn't find it in the digitalmars main page, the site map or the D page.
Also black t-shirts and/or shirts with the D logo (
http://d-programming-language.org/images/dlogo.png ) would be nice :)
(Funny fact: the german cafepress page translates Digital Mars to
"Digital März" and "Mars Mousepad" to "März Mousepad" - "März" is german
for the month "March")
Cheers,
- Daniel
Re: Instantiating Templates Structs with defaults parameter
>
>
> One simple issue is this:
>
> template whatevs(T...) { ... }
> whatevs!Foo; // did you mean to pass Foo or Foo!()? Both are legit!
>
>
Thanks Andrei for the enlightenment.
Regards
- Puneet
Re: Improving (foreach) ranges
On Thu, 09 Jun 2011 19:58:34 -0400, Andrej Mitrovic wrote: Yeah there was a big discussion about this IIRC. I can't recall the exact link to the topic, sorry. I know one of them was during tuple discussions. i.e. to use a..b..c instead of (a,b,c) The principal rational was a) '(,)' already has other meanings in D and b) '..' would allow for multi-dimensional slicing. But people felt this was ugly. And the multi-dimensional slicing discussions tend to advocate mapping a..b to [a,b].
Re: Should GC.malloc be considered 'pure'?
On Thu, 09 Jun 2011 13:51:31 -0400, KennyTM~ wrote: Given that the 'new' expression can be used in 'pure', should it be that GC allocation functions like GC.malloc, GC.qalloc and GC.extend (?) be weakly pure also? And should it apply to other managed allocators as well, e.g. the proposed TempAlloc? I'm asking this as one of the specializations of std.conv.toImpl calls GC.malloc, which is one of the 11 causes preventing std.conv.to from being pure, and GC.qalloc and GC.extend (and memcpy and Array.capacity) are used by std.array.appender (of pure range), and appender is also a major reason why std.conv.to is not pure. I think most of the GC functions should be usable in pure functions, but I don't know how we'd accomplish that from a technical perspective. Another thing to consider is whether GC.malloc should be valid during CTFE.
Re: Best article vote tally - WE HAVE TWO WINNERS!
"Steven Schveighoffer" wrote in message news:op.vwtvot14eav7ka@localhost.localdomain... > On Thu, 09 Jun 2011 17:27:14 -0400, Brad Anderson wrote: > >> A lot of technical groups that do voting use the Schulze method < >> http://en.wikipedia.org/wiki/Schulze_method>. Similar to IRV but >> technically better. I'm not sure how easy it is to do in practice. > > That looks cool, but we need a proven piece of software to do it :) > > I'd vote for that method. > The problem though is how do vote for the voting system without a voting system having already won the vote? Curse that stupid chicken and her damn egg!
Re: Best article vote tally - WE HAVE TWO WINNERS!
"Walter Bright" wrote in message news:isrlhg$1dle$1...@digitalmars.com... > On 6/9/2011 12:21 PM, Steven Schveighoffer wrote: >> We're developers, not politicians :) If you allow this, then we'll have >> to start >> creating youtube ads showing the other articles' past records of >> infidelity and >> such, and it just turns ugly. > > I only ask that the sexting stay off this n.g.! > If this were a women's modeling agency, I'd strongly disagree. But programmers...ugh, no...
