Re: An old topic (pun intended)
On 10/13/2011 07:14 PM, Ali Çehreli wrote: On Thu, 13 Oct 2011 09:18:46 -0700, Jonathan M Davis wrote: On Thursday, October 13, 2011 05:35:52 bearophile wrote: Davidson Corry: Did D2 ever implement the Eiffel old construct? At the moment there no prestate in D. I agree that prestate is an important sub-feature of contract programming. It was discussed two or three times, but the discussions didn't produce actual results. I think it was not implemented because I think Walter thinks D contract programming is a half failure (I don't agree on this) and because implementing the prestate is a bit tricky. I don't recall him ever saying anything about contract programming in D being a failure in any way. He had mentioned that at some point the implementation of contract programming had serious bugs but nobody had complained. IIRC, old was rejected because it added extra complication for little value. Yes, there were technical difficulties in making the stack frame at the call point available to the stack frame at the exit point. Why would that be required?
Re: An old topic (pun intended)
On 10/13/2011 08:25 PM, Davidson Corry wrote: On 10/13/2011 10:57 AM, bearophile wrote: Jonathan M Davis: I don't recall him ever saying anything about contract programming in D being a failure in any way. He said unittesting has changed the way you write code and has significantly decreased bugs count, while he was not equally happy about contract programming. From several things he has said, he looks disappointed by D contract programming. IIRC, old was rejected because it added extra complication for little value. It add some complexity, but I can't agree that it adds little value... And I don't remember it being rejected, I just remember the discussion stopped, like a river dying and drying up in a desert. Implementing DbC is tricky, and 'old' particularly so. For instance, what if the condition whose state-at-entry you want to inspect at exit happens to reside in a base class implemented in a different module? (Note that D supports separate compilation while Eiffel doesn't.) 'unittest' is a major win in D, and may as a practical matter alleviate much of the need for other kinds of testing. But... [opinion] ...unit testing and DbC are *orthogonal* or at least complementary, in my view. Conceptually, unit testing tests a class or object from the *outside* of its public boundaries, while DbC tests the object from *within*. They catch different classes (sic) of implementation error. Some bugs may be caught both ways, which is great. But some might slip by one, only to be caught by the other. Like any technique (including unit testing) DbC takes practice to learn how to do well, and it is new to most programmers even 25 years after Meyer brought it to the masses. There's a bootstrapping problem here: if DbC isn't fully implemented, it's not as useful. If it's not useful, programmers won't use it. If they don't use it, compiler implementers won't improve the implementation. And so on. Look, Walters are in scarce supply, and I don't want to jog their elbows on priorities -- they come up with so much other cool stuff! I'm just saying, 'old' would be nice. [/opinion] -- Davidson I don't agree that 'old' is very difficult to implement. Just evaluate what is inside the 'old' before you enter the in contract, store somewhere, maybe in hidden local variables, and make the data available in the out contract. Eiffel's 'old' does not do more than that. (but perhaps there are implementation details in DMD that make this more difficult than necessary. I don't know.)
Re: An old topic (pun intended)
On Sunday, October 16, 2011 19:13:09 Timon Gehr wrote: I don't agree that 'old' is very difficult to implement. Just evaluate what is inside the 'old' before you enter the in contract, store somewhere, maybe in hidden local variables, and make the data available in the out contract. Eiffel's 'old' does not do more than that. (but perhaps there are implementation details in DMD that make this more difficult than necessary. I don't know.) What if you're dealing with a class? You'd need to deep copy the entire object for it to work. There's no way built into the language to do that (not to mention that it would be horrifically inefficient). - Jonathan M Davis
Re: operator ~ does not check type?
On 10/13/2011 01:46 PM, Steven Schveighoffer wrote: On Thu, 13 Oct 2011 06:57:09 -0400, Cheng Wei riverch...@gmail.com wrote: == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article On Wed, 12 Oct 2011 09:46:57 -0400, Trass3r u...@known.com wrote: I believe that the primary reasoning for allowing the implicit conversion between int and dchar is so that code like this dchar c = 'a' + 7; That's a '+' though, not a '~'. Jonathan meant this better example ;) string s = hello; s ~= 'a' + 7; It's still fine if '~' does not allow implicit casting but '+' does. 'a' + 7 - 'h' which is already a dchar. So it can be appended to s without casting. A + B where the types of A and B are integral goes through integer promotion rules, inherited from C. Like them or not, they are very unlikely to change. This means dchar + int promotes to int, not dchar. Actually uint afaik. I think requiring a cast to go from int to dchar would be fine. It's not a very common operation, and it clearly causes novice issues. Another argument for requiring an explicit cast is that not every int can be converted to a valid dchar.
Re: An old topic (pun intended)
On 10/16/2011 07:31 PM, Jonathan M Davis wrote: On Sunday, October 16, 2011 19:13:09 Timon Gehr wrote: I don't agree that 'old' is very difficult to implement. Just evaluate what is inside the 'old' before you enter the in contract, store somewhere, maybe in hidden local variables, and make the data available in the out contract. Eiffel's 'old' does not do more than that. (but perhaps there are implementation details in DMD that make this more difficult than necessary. I don't know.) What if you're dealing with a class? You'd need to deep copy the entire object for it to work. There's no way built into the language to do that (not to mention that it would be horrifically inefficient). - Jonathan M Davis Eiffel does not do that either. (even though it _does_ have a built in deep copy feature) We don't have to over-engineer the feature, if somebody needs to deep-copy an object they can implement it themselves and use old(obj.deepCopy()).
Re: An old topic (pun intended)
Timon Gehr: Eiffel does not do that either. (even though it _does_ have a built in deep copy feature) We don't have to over-engineer the feature, if somebody needs to deep-copy an object they can implement it themselves and use old(obj.deepCopy()). I agree. A shallow prestate is quite better than not having it at all in D. Lately C# has implemented DbC, prestate too. I don't know how, but it's worth taking a look. Bye, bearophile
Implementing iterators for D custom data structures (best practices)
Hi All, I've not used D for long so hopefully this question isn't too stupid... Are there any best practices for implementing iterators in D? My understanding is that D follows a similar design approach to the STL RE containers - iterators - algs - adapters etc. Also, are there any examples of well written data structures that expose iterators?...I recall that in D only arrays have them (I may be wrong, I haven't looked). Any open source projects that are notoriously well implemented? Thanks in advance. GB
Re: Implementing iterators for D custom data structures (best practices)
On Monday, October 17, 2011 10:22:42 Granville Barnett wrote: Hi All, I've not used D for long so hopefully this question isn't too stupid... Are there any best practices for implementing iterators in D? My understanding is that D follows a similar design approach to the STL RE containers - iterators - algs - adapters etc. Also, are there any examples of well written data structures that expose iterators?...I recall that in D only arrays have them (I may be wrong, I haven't looked). Any open source projects that are notoriously well implemented? Thanks in advance. D code doesn't normally use iterators. It uses ranges, which are a similar but generally superior concept. http://www.informit.com/articles/printerfriendly.aspx?p=1407357 std.range and std.algorithm in particular make heavy use of ranges: http://d-programming-language.org/phobos/std_range.html http://d-programming-language.org/phobos/std_algorithm.html - Jonathan M Davis
Re: Implementing iterators for D custom data structures (best practices)
On 17/10/2011 10:55, Jonathan M Davis wrote: On Monday, October 17, 2011 10:22:42 Granville Barnett wrote: Hi All, I've not used D for long so hopefully this question isn't too stupid... Are there any best practices for implementing iterators in D? My understanding is that D follows a similar design approach to the STL RE containers - iterators - algs - adapters etc. Also, are there any examples of well written data structures that expose iterators?...I recall that in D only arrays have them (I may be wrong, I haven't looked). Any open source projects that are notoriously well implemented? Thanks in advance. D code doesn't normally use iterators. It uses ranges, which are a similar but generally superior concept. http://www.informit.com/articles/printerfriendly.aspx?p=1407357 std.range and std.algorithm in particular make heavy use of ranges: http://d-programming-language.org/phobos/std_range.html http://d-programming-language.org/phobos/std_algorithm.html - Jonathan M Davis Thanks Jonathan, I'll take a look. GB
Re: D and Programming Theory (Suggestions?)
On 13/10/2011 06:25, Ali Çehreli wrote: On Wed, 12 Oct 2011 21:10:00 +, Louis wrote: Does anyone know of any good books that talk about how computers work abstractly enough to be a solid cross language foundation? [...] There is no Beginning D or D For Dummies yet. There is a Turkish D book that targets programming novices: http://ddili.org/ders/d/index.html It starts with the basic concepts and and ends with Parallelization, Concurrency, Manual Memory Management, etc. Unfortunately, it doesn't go into programming theory or how computers work. It must be seen as some information from a craftsperson to new craftspeople. I am in the process of translating that book to English. This is the first time that I am giving a link to a very draft current state of the English translation: http://ddili.org/ders/d.en/index.html Contrary to what that page may makes one think, the Exceptions chapter has a draft translation as well: http://ddili.org/ders/d.en/exceptions.html And finally the Ranges chapter is a work in progress: http://ddili.org/ders/d.en/ranges.html All of the above is a draft and I haven't announced the English version yet. Not even here! :) I have to go over the chapters at least five more times to make many corrections. Although, since it's a translation, I don't think I will change the content much. Enjoy! Ali There are actually quite a few books that may help you...some more formal than others. For low-level application of ideas you might want to check out SSCLI Internals which uses the Rotor open source runtime as its running example - http://blogs.tedneward.com/2009/05/27/SSCLI+20+Internals.aspx. The material isn't advanced but obviously it will help if you can get a grounding in the model of how things are laid out first. For formal language theory there are many books: - Theories of Programming Languages (http://www.cs.cmu.edu/~jcr/tpl.html) - Types and Programming Languages (http://www.cis.upenn.edu/~bcpierce/tapl/) ...and countless others of operational, denotational, axiomatic semantics etc. (Just do a search.) The problem you may have is that most of this stuff is the bastion of a relative few and much of the literature is defined in terms that those few understand well (I'm talking about the non-trivial applications, e.g. a denotational semantics for a complete language.) HTH, GB
Re: How convice people that D it's wonderfull in a hour ?
On 09/10/2011 18:00, Zardoz wrote: Recently I've been asked if I could give a speech about D in my university. It will be of one hour of long. I not respond yet, but I think that I will do it. Actually I have the problem that I don't know well how explain well too many features and things of D that I like. I think that only talking about D's arrays and type system I will need around half-hour. Any recommendation of how I should focus it ? For me the selling points of D are as follows: - encourages what all good programmer do today but with the assistance of libraries, i.e. D provides unit testing and contracts that are actually part of the language...now there's no excuse - sanitized templates - there if you want it philosophy: you can use D to access the guts if you want to but in a way that is far more powerful than that offered by the likes of Java, C# etc (languages that your colleagues may well use very often) HTH GB
Re: An old topic (pun intended)
On 17-10-2011 02:43, bearophile wrote: Timon Gehr: Eiffel does not do that either. (even though it _does_ have a built in deep copy feature) We don't have to over-engineer the feature, if somebody needs to deep-copy an object they can implement it themselves and use old(obj.deepCopy()). I agree. A shallow prestate is quite better than not having it at all in D. Lately C# has implemented DbC, prestate too. I don't know how, but it's worth taking a look. Bye, bearophile Just for the record, the documentation is at: http://download.microsoft.com/download/C/2/7/C2715F76-F56C-4D37-9231-EF8076B7EC13/userdoc.pdf I agree that having old would be great, even if without deep copying (which is probably a terrible idea anyway). Also note that C# doesn't do deep copying here. - Alex
