Thread overview | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
November 17, 2005 D - Looks great! Open to changes still? | ||||
---|---|---|---|---|
| ||||
Hi, First off thanks so much all of you guys, and especially Walter, for working on what looks like a fantastic new language. My reaction and those of the colleagues I've mailed about it has bascially been "this is what we've been wanting for years". I love the way you've taken great ideas from all over the place and added a few new ones of your own. Is the language fairly fixed now, or are you still open to ideas? There are a couple of robustness suggestions I had that would find more bugs at compile time in a way that would be familiar to your hardened C/C++ programmer target audience. Thanks again Munch |
November 17, 2005 Re: D - Looks great! Open to changes still? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Munch | If you have a suggestion to make the language better, don't be afraid to say it. As of yet D is still a work in progress.
Munch wrote:
> Hi,
>
> First off thanks so much all of you guys, and especially Walter, for working on
> what looks like a fantastic new language. My reaction and those of the
> colleagues I've mailed about it has bascially been "this is what we've been
> wanting for years". I love the way you've taken great ideas from all over the
> place and added a few new ones of your own.
>
> Is the language fairly fixed now, or are you still open to ideas? There are a
> couple of robustness suggestions I had that would find more bugs at compile time
> in a way that would be familiar to your hardened C/C++ programmer target
> audience.
>
> Thanks again
>
> Munch
>
>
|
November 17, 2005 Re: D - Looks great! Open to changes still? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Munch | If your robustness suggestions are about 'const' and the like then try to dig into archives first. Andrew. http://terrainformatica.com "Munch" <Munch_member@pathlink.com> wrote in message news:dlj15s$2dqp$1@digitaldaemon.com... > Hi, > > First off thanks so much all of you guys, and especially Walter, for > working on > what looks like a fantastic new language. My reaction and those of the > colleagues I've mailed about it has bascially been "this is what we've > been > wanting for years". I love the way you've taken great ideas from all over > the > place and added a few new ones of your own. > > Is the language fairly fixed now, or are you still open to ideas? There > are a > couple of robustness suggestions I had that would find more bugs at > compile time > in a way that would be familiar to your hardened C/C++ programmer target > audience. > > Thanks again > > Munch > > |
November 18, 2005 Access parameter values in out clauses [was: Re: D - Looks great! Open to changes still?] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrew Fedoniouk | In article <dlj23c$2fmd$1@digitaldaemon.com>, Andrew Fedoniouk says... > >If your robustness suggestions are about 'const' and the like then try to dig into archives first. > Thanks for the tip - yes one of the ideas was about the different kinds of const. Wow this is really encouraging I found nothing but well presented, clearly thought out arguments in the archive - you guys are really working hard! OK well I've nothing to add on the const issue. From what I've gathered the reason const means "compile time constant" is 1. the read-only "in" parameter is basically part of the contract of the method (so presumably, the answer is to use contracts to enforce it at run time) 2. the effort of adding "contract-const" checking to the compiler is non-trivial So now I have a question: how do you specify read-onlyness in contracts? Is there some syntax I could use inside the contract blocks to mark a method parameter or class member as read-only? One really useful thing in specifying post conditions is to be able to get at the value of the parameters as they were when they were passed in. Is there syntax for that? What I mean is - in the same way that "result" gets bound to the return value on exit, it would be really handy if each parameter "p" got bound to say "p_in", so if you had parameters "alpha" and "kappa" in the function prototype then in the out block you'd have "alpha", "kappa", "alpha_in" and "kappa_in". This would make it straightfoward to check all kinds of post conditions, including read-onlyness. Looking at the example code: long square_root(long x) in { assert(x >= 0); } out (result) { assert((result * result) == x); } body { return math.sqrt(x); } That's fine as long as you have a nice short routine and you're sure that x is the same at the end as it is at the start. A lot of the time you have a longer routine though and can't be sure x hasn't been changed accidentally. In fact you might well want to assert specifically that the sqrt is performed on the value of x that was passed in, so you want to specify: long square_root(long x) in { assert(x >= 0); } out (result, x_in) { assert((result * result) == x_in); } body { return math.sqrt(x); } I'm new to the language so feel free to point me at the appropriate manual page/archive post if this has already been covered. Thanks for your time. Cheers Munch PS In article <dlj1t3$2f00$1@digitaldaemon.com>, clayasaurus says... > >If you have a suggestion to make the language better, don't be afraid to say it. As of yet D is still a work in progress. > Great - thanks for the encouragement =) |
November 18, 2005 Re: Access parameter values in out clauses [was: Re: D - Looks great! Open to changes still?] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Munch | Munch wrote: > From what I've gathered the reason const means "compile time constant" is > 1. the read-only "in" parameter is basically part of the contract of the method > (so presumably, the answer is to use contracts to enforce it at run time) > 2. the effort of adding "contract-const" checking to the compiler is non-trivial > > So now I have a question: how do you specify read-onlyness in contracts? There is no easy way to do this. Walter's argument against logical const-ness seems to be that it is misleading, as it's typically fairly easy to cast away the const qualifier and because even const operations are allowed to modify object state (mutable members or data referenced by pointers, most commonly). A hack might be to store a 'fingerprint' of an object (basically a memcpy of the object data) in the in clause and compare against it in the out clause, but this may still miss things (if data managed by reference is modified, for example). > Is there some syntax I could use inside the contract blocks to mark a method > parameter or class member as read-only? Not really. You could do this cooperatively by adding setReadOnly and clearReadOnly properties to a class, but there's nothing in the language to support this. > One really useful thing in specifying post conditions is to be able to get at > the value of the parameters as they were when they were passed in. Is there > syntax for that? Not at the moment, though it would be nice. Currently, the easiest thing here would be to use thread local storage to temporarily maintain copies of parameter data for comparison later. I'm planning on adding TLS support to Ares and when I do I suppose I should submit a patch for Phobos as well. Sean |
November 18, 2005 tightening up if statments[was: Re: D - Looks great! Open to changes still?] | ||||
---|---|---|---|---|
| ||||
Posted in reply to clayasaurus | OK so here is my other suggestion. It's very simple to implement from a compiler perspective - it adds robustness - it just needs a slight rearangement of the sytnax. I found a thread on it in the archives here: http://www.digitalmars.com/d/archives/1418.html Why not get rid of the looks-like-it's-nested-when-it-isn't bugs. Like this: while (i < 9) i++; j++; or this if (cond) <debug statement added to find bug>; <line of code intended to be conditional>; or more generally if (cond) <added code here>; <ORIGINAL conditional line of code>; <and/or more added code>; <and/or more added code>; This is one of those things that when you start out coding you kid yourself that you save time by skipping out the braces. As the years roll by you gradually come across bugs that are harder and harder to find, that had part of their cause in missing curlys. Sooner or later you learn to use braces everywhere. I occasionally do code reviews and whenever I've come across code which doesn't have curlys everywhere, I know I'm likely to find a bug somewhere in the code. This is easy to fix in the language syntax, thus: IfStatement: if ( Expression ) BlockStatement if ( Expression ) BlockStatement else BlockStatement if ( Expression ) BlockStatement else IfStatement Not enough motivation yet? Finally, this also kills one of the most insidious bugs in C/C++/Java: if (cond); <code intended to be conditional> I've only done this a few times in my programming life, mainly in the first few years, but boy did some of those bugs take a long time to find. Note that this one can't be fixed by voluntarily entering braces yourself: if (cond); { <code intended to be conditional> } The above syntax however, makes this a compile time error =) (Obviously the above also applies to "for", "while" etc. ) Regards Munch |
November 18, 2005 Re: tightening up if statments[was: Re: D - Looks great! Open to changes still?] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Munch | Munch wrote:
> OK so here is my other suggestion. It's very simple to implement from a compiler
> perspective - it adds robustness - it just needs a slight rearangement of the
> sytnax. I found a thread on it in the archives here:
> http://www.digitalmars.com/d/archives/1418.html
>
> Why not get rid of the looks-like-it's-nested-when-it-isn't bugs. Like this:
>
> IfStatement:
> if ( Expression ) BlockStatement
> if ( Expression ) BlockStatement else BlockStatement
> if ( Expression ) BlockStatement else IfStatement
>
I'm all for this. I almost always go ahead and use the braces anyway, because seemingly invariably if I leave them out, then I end up adding them later anyhow so I can insert some debugging code. D wouldn't be the first language to make them mandatory, really.
-- Chris Sauls
|
November 18, 2005 Re: tightening up if statments[was: Re: D - Looks great! Open to changes still?] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Munch | On Fri, 18 Nov 2005 00:32:54 +0000 (UTC), Munch wrote: > OK so here is my other suggestion. It's very simple to implement from a compiler perspective - it adds robustness - it just needs a slight rearangement of the sytnax. I found a thread on it in the archives here: http://www.digitalmars.com/d/archives/1418.html > > Why not get rid of the looks-like-it's-nested-when-it-isn't bugs. Like this: No argument from me. I'm constantly adding in braces anyway. > Not enough motivation yet? Finally, this also kills one of the most insidious bugs in C/C++/Java: > > if (cond); > <code intended to be conditional> The DMD compiler already catches this one. If you try it you get this message ... use '{ }' for an empty statement, not a ';' It is not well documented and it might not even be a part of the D-Language (as opposed to a compiler implementation). There is a small comment in the 'for' statement documentation that says ... Function bodies cannot be empty: for (int i = 0; i < 10; i++) ; // illegal Use instead: for (int i = 0; i < 10; i++) { } But it seems to apply to other statements as well. -- Derek (skype: derek.j.parnell) Melbourne, Australia 18/11/2005 12:07:43 PM |
November 18, 2005 Re: tightening up if statments[was: Re: D - Looks great! Open to changes still?] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Munch | In article <dlj7fm$2rk9$1@digitaldaemon.com>, Munch says... > >OK so here is my other suggestion. It's very simple to implement from a compiler perspective - it adds robustness - it just needs a slight rearangement of the sytnax. I found a thread on it in the archives here: http://www.digitalmars.com/d/archives/1418.html > >Why not get rid of the looks-like-it's-nested-when-it-isn't bugs. Like this: > >while (i < 9) >i++; j++; > >or this > >if (cond) ><debug statement added to find bug>; ><line of code intended to be conditional>; > >or more generally > >if (cond) ><added code here>; ><ORIGINAL conditional line of code>; <and/or more added code>; ><and/or more added code>; > >This is one of those things that when you start out coding you kid yourself that you save time by skipping out the braces. As the years roll by you gradually come across bugs that are harder and harder to find, that had part of their cause in missing curlys. Sooner or later you learn to use braces everywhere. I occasionally do code reviews and whenever I've come across code which doesn't have curlys everywhere, I know I'm likely to find a bug somewhere in the code. This is easy to fix in the language syntax, thus: > >IfStatement: >if ( Expression ) BlockStatement >if ( Expression ) BlockStatement else BlockStatement >if ( Expression ) BlockStatement else IfStatement > >Not enough motivation yet? Finally, this also kills one of the most insidious bugs in C/C++/Java: > >if (cond); ><code intended to be conditional> > >I've only done this a few times in my programming life, mainly in the first few years, but boy did some of those bugs take a long time to find. Note that this one can't be fixed by voluntarily entering braces yourself: > >if (cond); >{ ><code intended to be conditional> >} > >The above syntax however, makes this a compile time error =) > >(Obviously the above also applies to "for", "while" etc. ) > >Regards > >Munch > > I completely disagree. I enjoy the flexibility and I dont believe it should be limited just because someone, somewhere, might screw up. I would suggest using some sort of D lint application, such as a modified front end that would catch something like that, it would be fairly easy to do. |
November 18, 2005 Re: tightening up if statments[was: Re: D - Looks great! Open to changes still?] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Chris Sauls | "Chris Sauls" <ibisbasenji@gmail.com> wrote in message news:dlj8hv$2s2n$1@digitaldaemon.com... > Munch wrote: >> OK so here is my other suggestion. It's very simple to implement from a >> compiler >> perspective - it adds robustness - it just needs a slight rearangement of >> the >> sytnax. I found a thread on it in the archives here: >> http://www.digitalmars.com/d/archives/1418.html >> >> Why not get rid of the looks-like-it's-nested-when-it-isn't bugs. Like this: >> >> IfStatement: >> if ( Expression ) BlockStatement >> if ( Expression ) BlockStatement else BlockStatement >> if ( Expression ) BlockStatement else IfStatement >> > > I'm all for this. I almost always go ahead and use the braces anyway, because seemingly invariably if I leave them out, then I end up adding them later anyhow so I can insert some debugging code. D wouldn't be the first language to make them mandatory, really. > I agree entirely. It's been my experience where I'll insert a nifty little no-brace if statement, then have to debug that line; I put in a writefln call, and find out my wonderful no-brace trick doesn't work in this case, and I have to put in braces. > -- Chris Sauls |
Copyright © 1999-2021 by the D Language Foundation