View mode: basic / threaded / horizontal-split · Log in · Help
August 14, 2012
Re: Which D features to emphasize for academic review article
On 14/08/12 05:03, TJB wrote:
> On Monday, 13 August 2012 at 10:11:06 UTC, Don Clugston wrote:
>
>>  ... I have come to believe that there are very few algorithms
>> originally designed for integers, which also work correctly for
>> floating point.
>>
>> Integer code nearly always assumes things like, x + 1 != x, x == x,
>> (x + y) - y == x.
>>
>>
>> for (y = x; y < x + 10; y = y + 1) { .... }
>>
>> How many times does it loop?
>
> Don,
>
> I would appreciate your thoughts on the issue of re-implementing numeric
> codes like BLAS and LAPACK in pure D to benefit from the many nice
> features listed in this discussion.  Is it feasible? Worthwhile?
>
> Thanks,
>
> TJB

I found that when converting code for Special Functions from C to D, the 
code quality improved enormously. Having 'static if' and things like 
float.epsilon as built-ins makes a surprisingly large difference. It 
encourages correct code. (For example, it makes any use of magic numbers 
in the code look really ugly and wrong). Unit tests help too.

That probably doesn't apply so much to LAPACK and BLAS, but it would be 
interesting to see how far we can get with the new SIMD support.
August 14, 2012
Re: Which D features to emphasize for academic review article
On Saturday, 11 August 2012 at 05:41:23 UTC, Walter Bright wrote:
> On 8/10/2012 9:55 PM, F i L wrote:
>> On the first condition, without an 'else z = ...', or if the 
>> condition was removed at a later time, then you'll get a 
>> compiler error and be forced to explicitly assign 'z' 
>> somewhere above using it. So C# and D work in "similar" ways 
>> in this respect except that C# catches these issues at 
>> compile-time, whereas in D you need to:
>>   1. run the program
>>   2. get bad result
>>   3. hunt down bug
>
> However, and I've seen this happen, people will satisfy the 
> compiler complaint by initializing the variable to any old 
> value (usually 0), because that value will never get used. 
> Later, after other things change in the code, that value 
> suddenly gets used, even though it may be an incorrect value 
> for the use.


Note to Walter:

You're obviously correct that you can make an arbitrarily complex 
program to make it too difficult for the compiler to enforce 
initialization, the way C# does (and gives up in some cases).

What you seem to be missing is that the issue you're saying is 
correct in theory, but too much of a corner case in practice.

C#/Java programmers ___rarely___ run into the sort of issue 
you're mentioning, and even when they do, they don't have nearly 
as much of a problem with fixing it as you seem to think.

The only reason you run into this sort of problem (assuming you 
do, and it's not just a theoretical discussion) is that you're in 
the C/C++ mindset, and using variables in the C/C++ fashion.
If you were a "C#/Java Programmer" instead of a "C++ Programmer", 
you simply _wouldn't_ try to make things so complicated when 
coding, and you simply _wouldn't_ run into these problems the way 
you /think/ you would, as a C++ programmer.


Regardless, it looks to me like you two are arguing for two 
orthogonal issues:

F i L:  The compiler should detect uninitialized variables.
Walter: The compiler should choose initialize variables with NaN.


What I'm failing to understand is, why can't we have both?

1. Compiler _warns_ about "uninitialized variables" (or scalars, 
at least) the same way C# and Java do, __unless__ the user takes 
the address of the variable, in which case the compiler gives up 
trying to detect the flow (like C#).
Bonus points: Try to detect a couple of common cases (e.g. 
if/else) instead of giving up so easily.

2. In any case, the compiler initializes the variable with 
whatever default value Walter deems useful.


Then you get the best of both worlds:

1. You force the programmer to manually initialize the variable 
in most cases, forcing him to think about the default value. It's 
almost no trouble for

2. In the cases where it's not possible, the language helps the 
programmer catch bugs.


Why the heck D avoids #1, I have no idea.

It's one of the _major_ features of C# and Java that help promote 
correctness, and #1 looks orthogonal to #2 to me.



For users who don't like #1: They can suppress the warning. 
Nothing lost, anyway.
For users who DO like #1: They can turn it into an error. A lot 
to be gained.
August 14, 2012
Re: Which D features to emphasize for academic review article
On Tuesday, 14 August 2012 at 10:31:30 UTC, Mehrdad wrote:
> Note to Walter:
>
> You're obviously correct that you can make an arbitrarily 
> complex program to make it too difficult for the compiler to 
> enforce initialization, the way C# does (and gives up in some 
> cases).
>
> What you seem to be missing is that the issue you're saying is 
> correct in theory, but too much of a corner case in practice.
>
> C#/Java programmers ___rarely___ run into the sort of issue 
> you're mentioning, and even when they do, they don't have 
> nearly as much of a problem with fixing it as you seem to think.

Completely agree. I find it quite useful in C#. It helps a lot in 
hairy code (nested if/foreach/try) to make sure all cases are 
handled when initializing variable. Compilation errors can be 
simply dismissed by assigning a 'default' value to variable at 
the beginning the functions, but is generally a sloppy programing 
and you loose useful help of the compiler.

The rules in C# are very simple and almost verbatim can be 
applied to D
http://msdn.microsoft.com/en-us/library/aa691172%28v=vs.71%29.aspx
August 14, 2012
Re: Which D features to emphasize for academic review article
On 14/08/12 12:31, Mehrdad wrote:
> On Saturday, 11 August 2012 at 05:41:23 UTC, Walter Bright wrote:
>> On 8/10/2012 9:55 PM, F i L wrote:
>>> On the first condition, without an 'else z = ...', or if the
>>> condition was removed at a later time, then you'll get a compiler
>>> error and be forced to explicitly assign 'z' somewhere above using
>>> it. So C# and D work in "similar" ways in this respect except that C#
>>> catches these issues at compile-time, whereas in D you need to:
>>>   1. run the program
>>>   2. get bad result
>>>   3. hunt down bug
>>
>> However, and I've seen this happen, people will satisfy the compiler
>> complaint by initializing the variable to any old value (usually 0),
>> because that value will never get used. Later, after other things
>> change in the code, that value suddenly gets used, even though it may
>> be an incorrect value for the use.
>
>
> Note to Walter:
>
> You're obviously correct that you can make an arbitrarily complex
> program to make it too difficult for the compiler to enforce
> initialization, the way C# does (and gives up in some cases).
>
> What you seem to be missing is that the issue you're saying is correct
> in theory, but too much of a corner case in practice.
>
> C#/Java programmers ___rarely___ run into the sort of issue you're
> mentioning, and even when they do, they don't have nearly as much of a
> problem with fixing it as you seem to think.
>
> The only reason you run into this sort of problem (assuming you do, and
> it's not just a theoretical discussion) is that you're in the C/C++
> mindset, and using variables in the C/C++ fashion.
> If you were a "C#/Java Programmer" instead of a "C++ Programmer", you
> simply _wouldn't_ try to make things so complicated when coding, and you
> simply _wouldn't_ run into these problems the way you /think/ you would,
> as a C++ programmer.
>
>
> Regardless, it looks to me like you two are arguing for two orthogonal
> issues:
>
> F i L:  The compiler should detect uninitialized variables.
> Walter: The compiler should choose initialize variables with NaN.
>
>
> What I'm failing to understand is, why can't we have both?
>
> 1. Compiler _warns_ about "uninitialized variables" (or scalars, at
> least) the same way C# and Java do, __unless__ the user takes the
> address of the variable, in which case the compiler gives up trying to
> detect the flow (like C#).
> Bonus points: Try to detect a couple of common cases (e.g. if/else)
> instead of giving up so easily.
>
> 2. In any case, the compiler initializes the variable with whatever
> default value Walter deems useful.
>
>
> Then you get the best of both worlds:
>
> 1. You force the programmer to manually initialize the variable in most
> cases, forcing him to think about the default value. It's almost no
> trouble for
>
> 2. In the cases where it's not possible, the language helps the
> programmer catch bugs.
>
>
> Why the heck D avoids #1, I have no idea.

DMD detects uninitialized variables if you compile with -O. It's hard to 
implement the full Monty at the moment, because all that code is in the 
backend rather than the front-end.

> It's one of the _major_ features of C# and Java that help promote
> correctness, and #1 looks orthogonal to #2 to me.

Completely agree.
I always thought the intention was that assigning to NaN was simply a 
way of catching the difficult cases that slip through compile-time 
checks. Which includes the situation where the compile-time checking 
isn't yet implemented at all.
This is the first time I've heard the suggestion that it might never be 
implemented.

The thing which is really bizarre though, is float.init. I don't know 
what the semantics of it are.
August 14, 2012
Re: Which D features to emphasize for academic review article
Mehrdad wrote:
> Note to Walter:
>
> You're obviously correct that you can make an arbitrarily 
> complex program to make it too difficult for the compiler to 
> enforce initialization, the way C# does (and gives up in some 
> cases).
> 
> [ ... ]

I think some here are mis-interpreting Walters position 
concerning static analysis from our earlier conversation, so I'll 
share my impression of his thoughts.

I can't speak for Walter, of course, but I'm pretty sure that 
early on in our conversation he agreed that having the compiler 
catch local scope initialization issues was a good idea, or at 
least, wasn't a bad one (again, correct me if I'm wrong). I doubt 
he would be adverse to eventually having DMD perform this sort of 
static analysis to help developers, though I doubt it's a high 
priority for him.

The majority of the conversation after that was concerning 
struct/class fields defaults:

  class Foo
  {
      float x; // I think this should be 0.0f
               // Walter thinks it should be NaN
  }

In this situation static analysis can't help catch issues, and 
we're forced to rely on a default value of some kind. Both Walter 
and I have stated our opinion's reasoning previously, so I won't 
repeat them here.
August 14, 2012
Re: Which D features to emphasize for academic review article
On Tue, 14 Aug 2012 16:32:25 +0200, F i L <witte2008@gmail.com> wrote:

>    class Foo
>    {
>        float x; // I think this should be 0.0f
>                 // Walter thinks it should be NaN
>    }
>
> In this situation static analysis can't help catch issues, and we're  
> forced to rely on a default value of some kind.

Really? We can catch (or, should be able to) missing initialization
of stuff with @disable this(), but not floats?

Classes have constructors, which lend themselves perfectly to doing
exactly this (just pretend the member is a local variable).

Perhaps there are problems with structs without disabled default
constructors, but even those are trivially solvable by requiring
a default value at declaration time.

-- 
Simen
August 14, 2012
Re: Which D features to emphasize for academic review article
On Tuesday, 14 August 2012 at 14:46:30 UTC, Simen Kjaeraas wrote:
> On Tue, 14 Aug 2012 16:32:25 +0200, F i L <witte2008@gmail.com> 
> wrote:
>
>>   class Foo
>>   {
>>       float x; // I think this should be 0.0f
>>                // Walter thinks it should be NaN
>>   }
>>
>> In this situation static analysis can't help catch issues, and 
>> we're forced to rely on a default value of some kind.
>
> Really? We can catch (or, should be able to) missing 
> initialization
> of stuff with @disable this(), but not floats?
>
> Classes have constructors, which lend themselves perfectly to 
> doing
> exactly this (just pretend the member is a local variable).
>
> Perhaps there are problems with structs without disabled default
> constructors, but even those are trivially solvable by requiring
> a default value at declaration time.

You know, I never actually thought about it much, but I think 
you're right. I guess the same rules could apply to type fields.
August 14, 2012
Re: Which D features to emphasize for academic review article
On Tuesday, 14 August 2012 at 15:24:30 UTC, F i L wrote:
>> Really? We can catch (or, should be able to) missing 
>> initialization of stuff with @disable this(), but not floats?
>>
>> Classes have constructors, which lend themselves perfectly to 
>> doing exactly this (just pretend the member is a local 
>> variable).
>>
>> Perhaps there are problems with structs without disabled 
>> default constructors, but even those are trivially solvable by 
>> requiring a default value at declaration time.
>
> You know, I never actually thought about it much, but I think 
> you're right. I guess the same rules could apply to type fields.

Mmmm... What if you added a command that has a file/local scope? 
perhaps following the @disable this(), it could be @disable init; 
or @disable .init. This would only work for built-in types, and 
possibly structs with variables that aren't explicitly set with 
default values. It sorta already fits with what's there.

@disable init; //global scope in file, like @safe.

struct someCipher {
  @disable init; //local scope, in this case the whole struct.

  int[][] tables; //now gives compile-time error unless @disable 
this() used.
  ubyte[] key = [1,2,3,4]; //explicitly defined as a default
  this(ubyte[] k, int[][] t){key=k;tables=t;}
}

void myfun() {
  someCipher x; //compile time error since struct fails (But not 
at this line unless @disable this() used)
  someCipher y = someCipher([[1,2],[1,2]]); //should work as 
expected.
}
August 14, 2012
Re: Which D features to emphasize for academic review article
On Tuesday, 14 August 2012 at 15:24:30 UTC, F i L wrote:
> On Tuesday, 14 August 2012 at 14:46:30 UTC, Simen Kjaeraas 
> wrote:
>> On Tue, 14 Aug 2012 16:32:25 +0200, F i L 
>> <witte2008@gmail.com> wrote:
>>
>>>  class Foo
>>>  {
>>>      float x; // I think this should be 0.0f
>>>               // Walter thinks it should be NaN
>>>  }
>>>
>>> In this situation static analysis can't help catch issues, 
>>> and we're forced to rely on a default value of some kind.
>>
>> Really? We can catch (or, should be able to) missing 
>> initialization
>> of stuff with @disable this(), but not floats?
>>
>> Classes have constructors, which lend themselves perfectly to 
>> doing
>> exactly this (just pretend the member is a local variable).
>>
>> Perhaps there are problems with structs without disabled 
>> default
>> constructors, but even those are trivially solvable by 
>> requiring
>> a default value at declaration time.
>
> You know, I never actually thought about it much, but I think 
> you're right. I guess the same rules could apply to type fields.

C# structs, as you might recall, enforce definite initialization. 
:)

We could do the same for structs and classes... what I said 
doesn't just apply to local variables.
August 14, 2012
Re: Which D features to emphasize for academic review article
On Tuesday, 14 August 2012 at 14:32:26 UTC, F i L wrote:
> Mehrdad wrote:
>> Note to Walter:
>>
>> You're obviously correct that you can make an arbitrarily 
>> complex program to make it too difficult for the compiler to 
>> enforce initialization, the way C# does (and gives up in some 
>> cases).
>> 
>> [ ... ]
>
> I think some here are mis-interpreting Walters position 
> concerning static analysis from our earlier conversation, so 
> I'll share my impression of his thoughts.
>
> I can't speak for Walter, of course, but I'm pretty sure that 
> early on in our conversation he agreed that having the compiler 
> catch local scope initialization issues was a good idea, or at 
> least, wasn't a bad one (again, correct me if I'm wrong). I 
> doubt he would be adverse to eventually having DMD perform this 
> sort of static analysis to help developers, though I doubt it's 
> a high priority for him.


Ah, well if he's for it, then I misunderstood. I read through the 
entire thread (but not too carefully, just 1 read) and my 
impression was that he didn't like the idea because it would fail 
in some cases (and because D doesn't seem to love emitting 
compiler warnings in general), but if he likes it, then great. :)
3 4 5 6 7 8
Top | Discussion index | About this forum | D home