View mode: basic / threaded / horizontal-split · Log in · Help
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?
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?
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?]
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?]
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?]
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?]
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?]
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?]
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?]
"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
Top | Discussion index | About this forum | D home