On Tuesday 16 November 2010 20:53:04 Steven Schveighoffer wrote: > On Tue, 16 Nov 2010 16:04:18 -0500, Jonathan M Davis <jmdavisp...@gmx.com> > > wrote: > > On Tuesday 16 November 2010 12:37:10 bearophile wrote: > >> Jonathan M Davis: > >> > Pure is hard enough to deal with (especially since it we probably have > >> > made it the default, but it's too late for that now). > >> > >> Weakly pure on default isn't good for a language that is supposed to b e > >> somewhat compatible with C syntax, I think it breaks too many C > >> functions. > > > > Well, like I said, it's too late at this point, and really, it would be > > good to > > have a nice way to deal with C functions and purity (particularly since > > most of > > them are pure anyway), but the result at present is that most functions > > should > > be marked with pure. And if you're marking more functions with pure than > > not, > > that would imply that the default should be (at least ideally) impure. > > Regardless, however, it's not reasonable for D to go for impure rather > > than pure > > at this point. > > everything you are saying seems to be backwards, stop it! ;) > > 1. currently, the default is impure. > 2. Most functions will naturally be weakly pure, so making *pure* the > default would seem more useful. > > It seems backwards to me to think pure functions should be the default, I > mean, this isn't a functional language! But you also have to forget > everything you know about pure, because a weakly pure function is a very > useful idiom, and it is most certainly not compatible with functional > languages. It's both imperative and can accept and return mutable data. > > It makes me think that this is going to be extremely confusing for a > while, because people are so used to pure being equated with a functional > language, so when they see a function is pure but takes mutable data, they > will be scratching their heads. It would be awesome to make weakly pure > the default, and it would also make it so we have to change much less code.
II was not trying to separate out weakly pure and strongly pure. pure is pure as far as marking the functions go. Whether that purity strong or weak depends on the parameters. And since most functions should at least be weakly pure, you end up marking most functions with pure. Ideally, you'd be marking functions for the uncommon case rather than the common one. I do think that a serious downside to using pure to mark weak purity is that it's pretty much going to bury the difference. You're not using global variables, so you mark the function as pure. Whether it's actually strongly pure and thus the compiler can optimize it is then an optimization detail (though you can of course figure it out if you want to). I expect that that's pretty much what the situation is going to end up being. Of course, the fact that C functions aren't marked as pure (even though in most cases they are) tends to put a damper on things, and the fact that you have to create multiple versions of the same function in different static if blocks when the purity depends on a templated function or type that the function is using also puts a major damper on things. However, the overall trend will likely be to mark next to everything as pure. It would certainly be cool to have weakly pure be the default, but that would require adding impure or something similar for cases where a function can't even be weakly pure. I would think that ideally, you'd make the default weakly pure, have impure (or something similar) to mark functions which can't even be weakly pure, and have full-on pure just be detected by the compiler (since it should be able to do that if weakly pure is the default). pure could be dropped entirely, or you could keep it to enforce that a function actually be strongly pure, forcing you to change the function if something changes to make it only weakly pure or outright impure. But I don't see that change having any chance of being made. Even if you kept pure and made it strongly pure only, adding impure (or whatever you wanted to call it) would mean adding a keyword, which always seems to go over badly around here. It would also mean changing a fair bit of code (mostly due to stdin, stdout, and C functions I expect). I think that it would be ultimately worth it though, as long as we were willing to pay the pain up front. - Jonathan M Davis