On Mon, 19 Mar 2007 14:20:31 +0000 (UTC), Knud Soerensen wrote:

> Using a type system we can take the idea a step further.
> 
> typedef int ROWPOS;
> typedef int COLPOS;
> 
> foo
> {
>   ROWPOS rowPos;
>   COLPOS colPos;
> 
>   rowPos = colPos; // error at compiler time.
> }
> 

Currently D doesn't seem to support typedefs (user defined types) as
cleanly as I'd hope it would.

------------
 import std.stdio;
 typedef float age;
 typedef float len;

 void main()
 {
   age x;
   len y;
   float z = 4.321;

   x = 10;
   y = 5;
   //y = z; // fails but probably shouldn't
   //y = x; // correctly fails.
   y += x;  // incorrectly works.

   writefln("x=%s y=%s", x, y);
 }

------------

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
20/03/2007 5:05:40 PM

Sean Kelly wrote

> he distills it nicely by saying "don't throw away information." Most data have associated constraints,

Coincidentally I stumbled upon the fact, that statements may also carry information with them, which gets lost on resorting to the keywords provided by the given language.

I first noticed that when reading about the twixt-keyword of the nickle
system
  http://nickle.org/tutorial/x671.html#AEN706
which gives the generic if-keyword an additional meaning.

After this detection my mental habit to resort conditions to the if- keyword started to crumble.

Manfred_Nowak

Derek Parnell wrote:
> [...]
>  void main()
>  {
>    age x;
>    len y;
>    float z = 4.321;
> 
>    x = 10;
>    y = 5;
>    //y = z; // fails but probably shouldn't

I disagree.  Consider:

int x = 15;
months m = x; // Sound?

>    //y = x; // correctly fails.
>    y += x;  // incorrectly works.
> [...]

Ouch.

Dave

On Tue, 20 Mar 2007 00:18:24 -0800, David B. Held wrote:

> Derek Parnell wrote:
>> [...]
>>  void main()
>>  {
>>    age x;
>>    len y;
>>    float z = 4.321;
>> 
>>    x = 10;
>>    y = 5;
>>    //y = z; // fails but probably shouldn't
> 
> I disagree.  Consider:
> 
> int x = 15;
> months m = x; // Sound?

Of course it is. Unless you are talking about months-per-year, but that's not 'months' is it?

The trouble is that D's typedef does not allow you to extend the semantics of the base type, but that's what structs and classes are for, no?

The Euphoria language has a slightly different type construction mechanism which has its good side and bad side, but maybe something like it could be used to extend D's typedef mechanism.

 type month(object x)
    if not integer(x) then
       return 0
    end if

    if x < 1 then
       return 0
    end if

    if x > 12 then
       return 0
    end if

    return 1
 end type


 month m
 m = 15 -- FAILS with a type mismatch error.

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell

Derek Parnell wrote:
> [...]
> The trouble is that D's typedef does not allow you to extend the semantics
> of the base type, but that's what structs and classes are for, no?
> 
> The Euphoria language has a slightly different type construction mechanism
> which has its good side and bad side, but maybe something like it could be
> used to extend D's typedef mechanism.
> [...]

My understanding is that Contracts in D allow you to implement Ada-like SubRanges.  This is actually one of the things I really liked about the DbC support.  Is that not the case?

Dave

On Wed, 21 Mar 2007 00:35:46 -0800, David B. Held wrote:

> Derek Parnell wrote:
>> [...]
>> The trouble is that D's typedef does not allow you to extend the semantics
>> of the base type, but that's what structs and classes are for, no?
>> 
>> The Euphoria language has a slightly different type construction mechanism
>> which has its good side and bad side, but maybe something like it could be
>> used to extend D's typedef mechanism.
>> [...]
> 
> My understanding is that Contracts in D allow you to implement Ada-like SubRanges.  This is actually one of the things I really liked about the DbC support.  Is that not the case?

Contracts are optional. That is, if something is compiled with the -release switch, then contract code is not inserted into the executable. You cannot, and must not, rely on contract code for 'production' editions of software. It is only meant to be used during the development phases of an application, thus you should not use contracts to try and detect invalid input data for a function. Contract code should be used to detect logic errors and not data errors.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
21/03/2007 6:41:57 PM

> "Use a debugger only as a last resort. Having to resort to a debugger means your programming methodologies have failed."

i strongly disagree with this statement.
you can do a lot more with a debugger than printing exception
stacktraces and finding uninitialized variables. it enables you to
conveniently watch your program work step by step, watch intermediate
values, etc. to check whether it does the right thing, not just on a
low, technical level.
no syntax or programming methodologies will prevent you from
implementing faulty algorithms, they'll just help you to not fall into
pits that are part of the details of a programming language.

Knud Soerensen wrote:
> This morning I stumbled over a on-line book named "Writing Bug-Free C Code"
> http://www.duckware.com/bugfreec/index.html
> the gem of the book (chapter 4) is a way to implement an object model which
> provide better data hiding than C++ classes.
> 
> It also gives advise like:
> "Use a debugger only as a last resort. Having to resort to a debugger means
> your programming methodologies have failed."
> and
> "When fixing a bug, fix the underlying problem or cause of the bug and not just the bug itself."
> 
> D already have many feature which help the programmer make lesser bugs, but how can we make it even better ?
> 
> I think a good place to start is look at the last bugs reported by the users in released D programs, and consider if it is coursed by some fundamental flaw in D and what can be done to catch it earlier in development.
> 
> Maybe we need a place to report and discus this type of bugs.
> Is the newsgroup okay or would a bug-tracking system be a better option ?

> It is only meant to be used during the development phases of an
> application, thus you should not use contracts to try and detect invalid
> input data for a function. Contract code should be used to detect logic
> errors and not data errors.
> Derek

Actually Derek, contracts as a concept have no such limitation.  Their current implementation only performs logic errors, but logic errors may be extended to include proof-by-induction number range theories.  The contract specification could be used to generate spectral graphing of function i/o, utilize such to raise errors, document exacting constraints, etc.; however nobody has yet programmed such a useful tool.

It would probably be as complicated as gaining access to the AST for D (or parsing it) and then performing a hint of linear algebra; with the added problem of needing to provide cross platform gui for the spectral graph if one was desireable, or simply throw additional errors when a bounds was exceeded or unchecked.

On Wed, 21 Mar 2007 13:16:08 +0100, Jascha Wetzel wrote:

>> "Use a debugger only as a last resort. Having to resort to a debugger means your programming methodologies have failed."
> 
> i strongly disagree with this statement.
> you can do a lot more with a debugger than printing exception
> stacktraces and finding uninitialized variables. it enables you to
> conveniently watch your program work step by step, watch intermediate
> values, etc. to check whether it does the right thing, not just on a
> low, technical level.
> no syntax or programming methodologies will prevent you from
> implementing faulty algorithms, they'll just help you to not fall into
> pits that are part of the details of a programming language.
> 
Yes, the debugger can be very useful.
What he meant where that if your use a debugger for debugging
you obviously got a bug in your program.
Then when your find the bug your should go check your methods to see
why the bug slipped through.

I am working on a set of rules for bug free programing
and one of them is "Question every line of code"
and here the debugger is very useful, it allow you to
single step through you code and question everything.
But you should always do this not only when you get a bug.

Right now the rules looks like.


   1. Bug free programing is possible
   2. Every bug is due to a problem in the programming process
   3. Question every line of code
   4. Everything must scale
   5. Test all code
   6. Hide your data
   7. Count your mistakes
   8. Build it right the first time
   9. Interfaces are good, but inheritance is bad
  10. Always leave objects in a valid state

Knud Soerensen wrote:
> 
> I am working on a set of rules for bug free programing
> and one of them is "Question every line of code" and here the debugger is very useful, it allow you to single step through you code and question everything.
> But you should always do this not only when you get a bug.
>  Right now the rules looks like.
> 
> 
>    1. Bug free programing is possible
>    2. Every bug is due to a problem in the programming process
>    3. Question every line of code
>    4. Everything must scale
>    5. Test all code
>    6. Hide your data
>    7. Count your mistakes
>    8. Build it right the first time
>    9. Interfaces are good, but inheritance is bad
>   10. Always leave objects in a valid state

This is a good semi-related article:

http://www.fastcompany.com/online/06/writestuff.html


Sean