Jump to page: 1 25  
Page
Thread overview
D - Looks great! Open to changes still?
Nov 17, 2005
Munch
Nov 17, 2005
clayasaurus
tightening up if statments[was: Re: D - Looks great! Open to changes still?]
Nov 18, 2005
Munch
Nov 18, 2005
Chris Sauls
Nov 18, 2005
Ameer Armaly
Nov 18, 2005
Derek Parnell
Nov 18, 2005
Munchgreeble
Nov 18, 2005
JT
Nov 18, 2005
Regan Heath
Nov 18, 2005
Derek Parnell
Nov 18, 2005
dennis luehring
Re: tightening up if statments[was: Re: D - Looks great! Open to
Nov 18, 2005
JT
Nov 18, 2005
Don Clugston
Nov 18, 2005
dennis luehring
Nov 18, 2005
Regan Heath
Nov 18, 2005
Munchgreeble
Re: tightening up if statments[was: Re: D - Looks great! Open to
Nov 18, 2005
JT
Nov 18, 2005
JT
Nov 18, 2005
Munch
Nov 18, 2005
JT
Nov 18, 2005
Derek Parnell
Nov 18, 2005
Kris
Nov 19, 2005
Munchgreeble
Nov 19, 2005
Kris
Nov 19, 2005
Munchgreeble
Nov 19, 2005
Munchgreeble
Nov 19, 2005
J C Calvarese
Sorry [was: Re: tightening up if statments[was: Re: D - Looks great!]
Nov 19, 2005
Munchgreeble
Nov 19, 2005
J C Calvarese
OT Re: tightening up if statments[was: Re: D - Looks great! Open to
Nov 19, 2005
Munchgreeble
Nov 18, 2005
Kris
Nov 19, 2005
Munchgreeble
Nov 18, 2005
Bruno Medeiros
Nov 18, 2005
clayasaurus
Re: tightening up if statments[was: Re: D - Looks great! Open to
Nov 18, 2005
Dave
Nov 19, 2005
Dave
Nov 18, 2005
Derek Parnell
Nov 18, 2005
Munchgreeble
Nov 18, 2005
Sean Kelly
Nov 19, 2005
Larry Evans
Nov 17, 2005
Andrew Fedoniouk
Access parameter values in out clauses [was: Re: D - Looks great! Open to changes still?]
Nov 18, 2005
Munch
Nov 18, 2005
Sean Kelly
Nov 18, 2005
Munchgreeble
November 17, 2005
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
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
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
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
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
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
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
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
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
"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


« First   ‹ Prev
1 2 3 4 5