Derek Parnell wrote:
> I use ...
> 
>  char c;
>  int v = (cast(int)c - '0')
> 
> To me it the same as assuming that boolean values are integers.

You suggest writing things like

  for (int c=0x100;c!=0;--c) {...}

or

  for (int c=0x100;cast(bool)c;--c) {...}

?

UGH! :-)

Maybe another example what systems programming language might mean:
A language that encourages the programmer to know what is going on
behind the scenes, after compilation, and allows her to make use of
that knowledge.
If I know that testing a condition is nothing but comparing a number
to zero, writing "if (number!=0)" just becomes redundant.

Regards, Frank

On Tue, 24 Jul 2007 08:39:49 +0200, 0ffh wrote:

> Derek Parnell wrote:
>> I use ...
>> 
>>  char c;
>>  int v = (cast(int)c - '0')
>> 
>> To me it the same as assuming that boolean values are integers.
> 
> You suggest writing things like
> 
>    for (int c=0x100;c!=0;--c) {...}
> 
> or
> 
>    for (int c=0x100;cast(bool)c;--c) {...}
> 
> ?

Yep. That's how I tend to do my non-assembler coding, but with a lot more white space, less 'jargon', and avoid magic numbers :-)

  const MaxWidgetCount = 256;
  for (int lRemaining = MaxWidgetCount; lRemaining != 0; lRemaining--)
  {
      ...
  }

> UGH! :-)
>
> Maybe another example what systems programming language might mean:
> A language that encourages the programmer to know what is going on
> behind the scenes, after compilation, and allows her to make use of
> that knowledge.
> If I know that testing a condition is nothing but comparing a number
> to zero, writing "if (number!=0)" just becomes redundant.

I'm different. I write code so other people can read it with as little effort as possible ... and sometimes I even succeed <G>

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
24/07/2007 4:53:26 PM

Wonderful, thank you very much!

On the subject of traits, would it be possible / helpful to have a trait to enumerate all members of a module?

Kirk McDonald wrote:
> Walter Bright wrote:
>>
>> http://www.digitalmars.com/d/1.0/changelog.html
>> http://ftp.digitalmars.com/dmd.1.019.zip
>>
>> http://www.digitalmars.com/d/changelog.html
>> http://ftp.digitalmars.com/dmd.2.003.zip
> 
> Well, this __traits stuff is certainly going to give me something to think about. One note: the lexical page doesn't seem to list it as a keyword.
> 
> How many times have I rewritten Pyd? Three? Well, no matter. This should make things interesting again.
> 

Kirk, I saw your blog post regarding this.  Congrats.  Looks like you had a bumper-crop of code reductions!

-- 
- EricAnderton at yahoo

Reply to 0ffh,

> If I know that testing a condition is nothing but comparing a number
> to zero, writing "if (number!=0)" just becomes redundant.

actually ASM usually has built in >, < and = comparisons, some times these implicitly use 0 for the other side, but it still it is not /just/ a zero test.

Robert Fraser wrote:
> Hmmmm.... it just seems to disturb the zen of D (having one keyword with two underscores), and I think it'll be used just as much as some other keywords, whether it's buried in templates or not.

I agree. keywords with underscores (no matter where and how many) are just wrong.

--serg.

0ffh wrote:
> So we get:
> 
>   char +/- int  : okay
>   int  +/- char : okay
>   char  -  char : okay
>   char  +  char : baddie!
> 
> I Look at this this way: Nobody in his right mind is gonna
> try to put into the compiler, which kinds of calculation
> make "sense" and which don't; that would be just insane.

But I do things like:

	c += 'a' - 'A';   // to lower case

The problem with explicit casts is that they are a brute force method, and subvert static type checking. A well designed systems allows a balance between implicit casting and strong type checking so that explicit casts are rarely needed in properly written programs.

Pragma wrote:
> Kirk McDonald wrote:
> 
>> Walter Bright wrote:
>>
>>>
>>> http://www.digitalmars.com/d/1.0/changelog.html
>>> http://ftp.digitalmars.com/dmd.1.019.zip
>>>
>>> http://www.digitalmars.com/d/changelog.html
>>> http://ftp.digitalmars.com/dmd.2.003.zip
>>
>>
>> Well, this __traits stuff is certainly going to give me something to think about. One note: the lexical page doesn't seem to list it as a keyword.
>>
>> How many times have I rewritten Pyd? Three? Well, no matter. This should make things interesting again.
>>
> 
> Kirk, I saw your blog post regarding this.  Congrats.  Looks like you had a bumper-crop of code reductions!
> 

The linked-to changeset was from last November, when D got tuples. I haven't committed anything using __traits, yet.

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org

Derek Parnell wrote:
> On Mon, 23 Jul 2007 21:25:31 -0700, James Dennett wrote:
> 
>> BCS wrote:
>>> Reply to Derek,
>>>
>>>> Are you serious??? Why are we allowed to do mathematics with characters?
>>>>
>>> I have done this a few times
>>>
>>> char c;
>>> int v = (c - '0')
>> Perfectly reasonable, as is character +/- integer, but character + character is nonsense, just as it makes sense to subtract two points yielding a vector, or add a vector to a point (yielding a point) but no sense to "add" two points in a mere affine space.
> 
> I'm sorry. I am a bit of a pedantic bastard at times.

You're in good company.

> I use ...
> 
>  char c;
>  int v = (cast(int)c - '0')
> 
> To me it the same as assuming that boolean values are integers.

Subtracting a char from an int, as you appear to be doing above, also makes no sense... or do casts in D bind insanely loosely?  Subtracting one char from another actually makes more sense (see analogy above to affine geometry).  It's a reasonable question to ask "which offset must I add to this char to get to this other char", but not "what's the difference between the number 27 and the character 'o'?".

(And yes, I feel guilty/contaminated if I ever treat a boolean
value as an integer, or vice versa.)

-- James

Walter Bright wrote:
> 0ffh wrote:
>> So we get:
>>
>>   char +/- int  : okay
>>   int  +/- char : okay
>>   char  -  char : okay
>>   char  +  char : baddie!
>>
>> I Look at this this way: Nobody in his right mind is gonna try to put into the compiler, which kinds of calculation make "sense" and which don't; that would be just insane.
> 
> But I do things like:
> 
>     c += 'a' - 'A';   // to lower case

Which is fine according to the above rules: it uses char-char
(giving int, I hope), and then char+int (giving char, with
risk of overflow/wraparound in more general contexts but not
in this case).

> The problem with explicit casts is that they are a brute force method, and subvert static type checking. A well designed systems allows a balance between implicit casting and strong type checking so that explicit casts are rarely needed in properly written programs.

That's why I like the rules above.  They permit all sane uses of arithmetic on characters while disallowing many erroneous uses, and with no need for casts.

Not that I'm actually seriously suggesting changing D in this direction.  This just isn't worth going against what most programmers with C/C++/Java-like backgrounds expect.

-- James