D - suggestion for cast expression

Now, D's cast excpressions are of the form:

uint a = 0xFF;
byte b = cast(byte) a;

But, casted expressions or cast expressions are often parenthesized as:

uint a = 0x98_F1_9F_A2;
byte b = cast(byte) (a >> 24);

or

void foo(A a)
in   { assert(cast(B) a); }
body { (cast(B) a).foo(); }

I think that such an expression is not beautiful.
So, I suggest following form:

uint a = 0xFF;
byte b = cast(byte, a >> 24);

void foo(A a)
in   { assert(cast(B, a)); }
body { cast(B, a).foo(); }

in order to free us from troublesome operator precedence.

Robert (Japanese)

Dec 06 2003

"Sean L. Palmer" <palmer.sean verizon.net> writes:

This is an ongoing discussion, and this has been suggested before.  Very
recently in fact.

Your replacement itself has a similar flaw..  it's sort of ambiguous with
the comma operator and it's hard for people to remember which one comes
first, the type or the value to cast.

You can either think of it to, or from.  Either way you have an expression,
either type expression or value expression, and either one can need
parenthesis to form it into a group.  So why not do it with property syntax,
i.e.

x.cast(Foo*)->Bar();
    vs.
(Foo*).cast(x)->Bar();

or

template (T) T* alignPtr(T* p, uint amt)
{
    return ((p.cast(int) + amt - 1) & (amt - 1)).cast(T*);
}
    vs.
template (T) T* alignPtr(T* p, uint amt)
{
    return (T*).cast((int.cast(p) + amt - 1) & (amt - 1));
}

I think the former (variable on left, type on right) is most intuitive.  I
noticed this while writing the above, that during the second forms I found
myself having to backtrack to add the type after having written the
variable.

Maybe D could accept both forms and automatically know that the variable is
being casted to the type, it shouldn't matter which one is the "object" and
which one is the function argument.

Well it's good to see new faces around here Robert.

BTW since you're Japanese, I have a question.  Do you write D in Japanese,
or not?  Would you?

Sean

"Robert" <Robert_member pathlink.com> wrote in message
news:bqu2su$1k8e$1 digitaldaemon.com...
 Now, D's cast excpressions are of the form:

 uint a = 0xFF;
 byte b = cast(byte) a;

 But, casted expressions or cast expressions are often parenthesized as:

 uint a = 0x98_F1_9F_A2;
 byte b = cast(byte) (a >> 24);

 or

 void foo(A a)
 in   { assert(cast(B) a); }
 body { (cast(B) a).foo(); }

 I think that such an expression is not beautiful.
 So, I suggest following form:

 uint a = 0xFF;
 byte b = cast(byte, a >> 24);

 void foo(A a)
 in   { assert(cast(B, a)); }
 body { cast(B, a).foo(); }

 in order to free us from troublesome operator precedence.

 Robert (Japanese)

Dec 07 2003

Robert <Robert_member pathlink.com> writes:

In article <bquosu$2s01$1 digitaldaemon.com>, Sean L. Palmer says...
This is an ongoing discussion, and this has been suggested before.  Very
recently in fact.


Oh, I'm sorry.  I missed to find them.


Your replacement itself has a similar flaw..  it's sort of ambiguous with
the comma operator and it's hard for people to remember which one comes
first, the type or the value to cast.
You can either think of it to, or from.  Either way you have an expression,
either type expression or value expression, and either one can need
parenthesis to form it into a group.  So why not do it with property syntax,
i.e.

x.cast(Foo*)->Bar();
    vs.
(Foo*).cast(x)->Bar();

or

template (T) T* alignPtr(T* p, uint amt)
{
    return ((p.cast(int) + amt - 1) & (amt - 1)).cast(T*);
}
    vs.
template (T) T* alignPtr(T* p, uint amt)
{
    return (T*).cast((int.cast(p) + amt - 1) & (amt - 1));
}

I think the former (variable on left, type on right) is most intuitive.  I
noticed this while writing the above, that during the second forms I found
myself having to backtrack to add the type after having written the
variable.

Maybe D could accept both forms and automatically know that the variable is
being casted to the type, it shouldn't matter which one is the "object" and
which one is the function argument.


Hmmm.. indeed.

I'd like to express my opinions of it,
but I think that I should discuss it at main thread of this subject.


Well it's good to see new faces around here Robert.


I'm glad to see you, too, Mr. Palmer.


BTW since you're Japanese, I have a question.  Do you write D in Japanese,
or not?  Would you?

Sean


I write D in english, since I use now Cygwin's `vi' editor.
It doesn't support japanese...
But, I will use english except for comments in the other case.
Because, switching IME (input method editor) hinders smooth programming,
even though it can be done by only one key.

Robert (Japanese)

Dec 07 2003

"Walter" <walter digitalmars.com> writes:

"Robert" <Robert_member pathlink.com> wrote in message
news:bqv1or$6fs$1 digitaldaemon.com...
 I write D in english, since I use now Cygwin's `vi' editor.
 It doesn't support japanese...
 But, I will use english except for comments in the other case.
 Because, switching IME (input method editor) hinders smooth programming,
 even though it can be done by only one key.


Hi Robert! I'd actually prefer you wrote D in Japanese, as a way to help
thoroughly thrash out the international support in the language. Isn't there
a good unicode text editor that supports Japanese?

Jan 11 2004

"Robert" <no spam.ne.jp> writes:

"Walter" <walter digitalmars.com> wrote in message
news:bttk3c$50r$1 digitaldaemon.com...
 "Robert" <Robert_member pathlink.com> wrote in message
 news:bqv1or$6fs$1 digitaldaemon.com...
 I write D in english, since I use now Cygwin's `vi' editor.
 It doesn't support japanese...
 But, I will use english except for comments in the other case.
 Because, switching IME (input method editor) hinders smooth programming,
 even though it can be done by only one key.


 Hi Robert! I'd actually prefer you wrote D in Japanese, as a way to help
 thoroughly thrash out the international support in the language. Isn't


 a good unicode text editor that supports Japanese?


Though normally the Japanese uses Shift-JIS character set in Windows and
Macintosh, EUC-JP in Linux, Shift-JIS or EUC-JP in UNIX, and JIS in E-mail,
Windows XP's "notepad", "Hidemaru editor" (shareware), etc. support unicode
text.

But why I (or we?) don't use Japanese for identifiers is not due to text
editors.
It's because it is trouble to input text that ASCII characters (keywords,
operators, and English identifiers of libraries) and Japanese characters are
frequently mixed.

In Japanese (and probably many other language not using alphabet) IME,
there are two input modes.
In one mode, one can input ASCII characters.
In another mode, one can input Japanese characters.
If now in Japanese mode, in order to input ASCII code one must switch the
input mode or convert input characters to ASCII character.
Of course, both ways can be done by pressing a key, but they hinders smooth
programming.

So, I'm afraid that it's good enough that Japanese characters can be used in
comments or string/character literals.
The Japanese are used to it.
(But, Unicode identifiers are maybe useful for The French, German, etc.
using only alphabet and a few accent or umlaut)



Windows95/98/Me support only 'A' (local) APIs (e.g. CreateWindowExA), don't
support 'W' (Unicode) APIs (e.g. CreateWindowExW).
In order to use 'CreateWindowEx' in Windows95/98/Me, we must use Shift-JIS,
not Unicode.

So  for the international support, even if one must write the source codes
itself only in Unicode, the program should handle MBCS (Multi-Byte Character
Set) IMO.

For instance:

    extern(Windows) {
        // lchar denotes local character set
        BOOL SetWindowTextA(HWND, lchar);
        BOOL SetWindowTextW(HWND, wchar);
    }
    version(CharTrait_Local) {
        alias lchar tchar;
        alias SetWindowTextA SetWindowText;
    } else version(CharTrait_Unicode) {
        alias wchar tchar;
        alias SetWindowTextW SetWindowText;
    }

    tchar[] text = "...Japanese...";
    SetWindowText(wnd, text);

"wcstombs/mbstowcs" C functions, "WideCharToMultiByte/MultiByteToWideChar"
Windows APIs, or "iconv" library will help for you to impliment it.



BTW, is it fixed?
D/19978

Jan 12 2004

"Walter" <walter digitalmars.com> writes:

"Robert" <no spam.ne.jp> wrote in message
news:btttpv$n3j$1 digitaldaemon.com...
 Though normally the Japanese uses Shift-JIS character set in Windows and
 Macintosh, EUC-JP in Linux, Shift-JIS or EUC-JP in UNIX, and JIS in


 Windows XP's "notepad", "Hidemaru editor" (shareware), etc. support


 text.

 But why I (or we?) don't use Japanese for identifiers is not due to text
 editors.
 It's because it is trouble to input text that ASCII characters (keywords,
 operators, and English identifiers of libraries) and Japanese characters


 frequently mixed.

 In Japanese (and probably many other language not using alphabet) IME,
 there are two input modes.
 In one mode, one can input ASCII characters.
 In another mode, one can input Japanese characters.
 If now in Japanese mode, in order to input ASCII code one must switch the
 input mode or convert input characters to ASCII character.
 Of course, both ways can be done by pressing a key, but they hinders


 programming.

 So, I'm afraid that it's good enough that Japanese characters can be used


 comments or string/character literals.
 The Japanese are used to it.
 (But, Unicode identifiers are maybe useful for The French, German, etc.
 using only alphabet and a few accent or umlaut)



 Windows95/98/Me support only 'A' (local) APIs (e.g. CreateWindowExA),


 support 'W' (Unicode) APIs (e.g. CreateWindowExW).
 In order to use 'CreateWindowEx' in Windows95/98/Me, we must use


 not Unicode.

 So  for the international support, even if one must write the source codes
 itself only in Unicode, the program should handle MBCS (Multi-Byte


 Set) IMO.

 For instance:

     extern(Windows) {
         // lchar denotes local character set
         BOOL SetWindowTextA(HWND, lchar);
         BOOL SetWindowTextW(HWND, wchar);
     }
     version(CharTrait_Local) {
         alias lchar tchar;
         alias SetWindowTextA SetWindowText;
     } else version(CharTrait_Unicode) {
         alias wchar tchar;
         alias SetWindowTextW SetWindowText;
     }

     tchar[] text = "...Japanese...";
     SetWindowText(wnd, text);

 "wcstombs/mbstowcs" C functions, "WideCharToMultiByte/MultiByteToWideChar"
 Windows APIs, or "iconv" library will help for you to impliment it.


I think I understand now.

 BTW, is it fixed?
 D/19978


Yes.

Jan 16 2004

Robert <Robert_member pathlink.com> writes:

 BTW, is it fixed?
 D/19978


Yes.


It seems that is not fixed also in DMD 0.79.

The bug of struct with union is fixed indeed,
but that of union with struct is not.
The above should output five 0s.

Jan 22 2004

"Sean L. Palmer" <palmer.sean verizon.net> writes:

EmEditor (Emurasoft) has good Unicode support.

My suggestion to Robert is to use some sort of preprocessor (M4?) to map
Japanese keywords into English keywords.  Guess that wouldn't handle the
operators though.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:bttk3c$50r$1 digitaldaemon.com...
 "Robert" <Robert_member pathlink.com> wrote in message
 news:bqv1or$6fs$1 digitaldaemon.com...
 I write D in english, since I use now Cygwin's `vi' editor.
 It doesn't support japanese...
 But, I will use english except for comments in the other case.
 Because, switching IME (input method editor) hinders smooth programming,
 even though it can be done by only one key.


 Hi Robert! I'd actually prefer you wrote D in Japanese, as a way to help
 thoroughly thrash out the international support in the language. Isn't


 a good unicode text editor that supports Japanese?

Jan 12 2004

"Robert" <no spam.ne.jp> writes:

Japanese (and proberbly Chinese) language has one more problem.
We need a few steps to input Japanese.
First, enter the pronunciation in Hiragana (a kind of Japanese characters).
Next, choise Kanji (Chinese characters) which is wanted now (this step isn't
needed to input Hiragana).
Last, press enter key to determine it.

So, the input cost is almost same or higher than that of the hybrid program.
i.e. input cost relation becomes:

    low (better) <------------------> high (worse)
    Full-English < Hybrid (English and Japanese) <= Full-Japanese

And their readabilities:

    low (worse) <------------------> high (better)
    Full-Japanese <= Full-English < Hybrid (English and Japanese)

since the Japanese aren't used to reading full-Japanese programs.
So, if I use Japanese identifiers, I will write hybrid programs.

I like Japanese language, but it is too complicated to program...


"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:btupgi$25k5$1 digitaldaemon.com...
 EmEditor (Emurasoft) has good Unicode support.

 My suggestion to Robert is to use some sort of preprocessor (M4?) to map
 Japanese keywords into English keywords.  Guess that wouldn't handle the
 operators though.

 Sean

 "Walter" <walter digitalmars.com> wrote in message
 news:bttk3c$50r$1 digitaldaemon.com...
 "Robert" <Robert_member pathlink.com> wrote in message
 news:bqv1or$6fs$1 digitaldaemon.com...
 I write D in english, since I use now Cygwin's `vi' editor.
 It doesn't support japanese...
 But, I will use english except for comments in the other case.
 Because, switching IME (input method editor) hinders smooth






 even though it can be done by only one key.


 Hi Robert! I'd actually prefer you wrote D in Japanese, as a way to help
 thoroughly thrash out the international support in the language. Isn't


 a good unicode text editor that supports Japanese?

Jan 12 2004

davepermen <davepermen_member pathlink.com> writes:

and i don't know why anyone should.. i think its the worst idea ever to allow
unicode for coding.. who has a unicode keyboard? no one.. so typing itself gets
stupid.

and the next.. what if linux would've been coded by the language of the
developers? there we have finish, there we have french, there we have japanese,
there we have swiss-german, there we have klingon, there we have raetoromantsch,
there we have polish, etc..

how about staying in english?

i don't code in swiss-german eighter.. i'd never even thought about doing so.

this is the new babilon. its called internet.

oh and, i've seen quite some japanese (or so? i just see tons of squares:D)
pages about D programming. i think its dissapointing, because they are rather
good (as far as i can tell from the code), but i will never understand a word of
it.

In article <btusbn$2ak3$1 digitaldaemon.com>, Robert says...
Japanese (and proberbly Chinese) language has one more problem.
We need a few steps to input Japanese.
First, enter the pronunciation in Hiragana (a kind of Japanese characters).
Next, choise Kanji (Chinese characters) which is wanted now (this step isn't
needed to input Hiragana).
Last, press enter key to determine it.

So, the input cost is almost same or higher than that of the hybrid program.
i.e. input cost relation becomes:

    low (better) <------------------> high (worse)
    Full-English < Hybrid (English and Japanese) <= Full-Japanese

And their readabilities:

    low (worse) <------------------> high (better)
    Full-Japanese <= Full-English < Hybrid (English and Japanese)

since the Japanese aren't used to reading full-Japanese programs.
So, if I use Japanese identifiers, I will write hybrid programs.

I like Japanese language, but it is too complicated to program...


"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:btupgi$25k5$1 digitaldaemon.com...
 EmEditor (Emurasoft) has good Unicode support.

 My suggestion to Robert is to use some sort of preprocessor (M4?) to map
 Japanese keywords into English keywords.  Guess that wouldn't handle the
 operators though.

 Sean

 "Walter" <walter digitalmars.com> wrote in message
 news:bttk3c$50r$1 digitaldaemon.com...
 "Robert" <Robert_member pathlink.com> wrote in message
 news:bqv1or$6fs$1 digitaldaemon.com...
 I write D in english, since I use now Cygwin's `vi' editor.
 It doesn't support japanese...
 But, I will use english except for comments in the other case.
 Because, switching IME (input method editor) hinders smooth






 even though it can be done by only one key.


 Hi Robert! I'd actually prefer you wrote D in Japanese, as a way to help
 thoroughly thrash out the international support in the language. Isn't


 a good unicode text editor that supports Japanese?

Jan 12 2004

"Robert" <no spam.ne.jp> writes:

Japanese has one more problem...
(oh... Japanese has many many problems...)
Shift-JIS, a kind of Japanese code set used in Windows and Macintosh, needs
one or two bytes per character.
The one-byte code sets are ASCII code set and Hankaku-Kana code set.

In case of the two-byte code set,
The first bytes are out of range of the one-byte code sets,
but the second bytes are not.
Unfortunately, the range of the second bytes includes backslash.
This often causes troublesome problem in string literals when using
non-internationalized compilers (e.g. Cygwin's GCC).
Unicode is the easiest way to solve it.


"davepermen" <davepermen_member pathlink.com> wrote in message
news:btutlc$2cvh$1 digitaldaemon.com...
 and i don't know why anyone should.. i think its the worst idea ever to


 unicode for coding.. who has a unicode keyboard? no one.. so typing itself


 stupid.

 and the next.. what if linux would've been coded by the language of the
 developers? there we have finish, there we have french, there we have


 there we have swiss-german, there we have klingon, there we have


 there we have polish, etc..

 how about staying in english?

 i don't code in swiss-german eighter.. i'd never even thought about doing


 this is the new babilon. its called internet.

 oh and, i've seen quite some japanese (or so? i just see tons of


 pages about D programming. i think its dissapointing, because they are


 good (as far as i can tell from the code), but i will never understand a


 it.

 In article <btusbn$2ak3$1 digitaldaemon.com>, Robert says...
Japanese (and proberbly Chinese) language has one more problem.
We need a few steps to input Japanese.
First, enter the pronunciation in Hiragana (a kind of Japanese




Next, choise Kanji (Chinese characters) which is wanted now (this step




needed to input Hiragana).
Last, press enter key to determine it.

So, the input cost is almost same or higher than that of the hybrid




i.e. input cost relation becomes:

    low (better) <------------------> high (worse)
    Full-English < Hybrid (English and Japanese) <= Full-Japanese

And their readabilities:

    low (worse) <------------------> high (better)
    Full-Japanese <= Full-English < Hybrid (English and Japanese)

since the Japanese aren't used to reading full-Japanese programs.
So, if I use Japanese identifiers, I will write hybrid programs.

I like Japanese language, but it is too complicated to program...


"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:btupgi$25k5$1 digitaldaemon.com...
 EmEditor (Emurasoft) has good Unicode support.

 My suggestion to Robert is to use some sort of preprocessor (M4?) to






 Japanese keywords into English keywords.  Guess that wouldn't handle






 operators though.

 Sean

 "Walter" <walter digitalmars.com> wrote in message
 news:bttk3c$50r$1 digitaldaemon.com...
 "Robert" <Robert_member pathlink.com> wrote in message
 news:bqv1or$6fs$1 digitaldaemon.com...
 I write D in english, since I use now Cygwin's `vi' editor.
 It doesn't support japanese...
 But, I will use english except for comments in the other case.
 Because, switching IME (input method editor) hinders smooth






 even though it can be done by only one key.


 Hi Robert! I'd actually prefer you wrote D in Japanese, as a way to








 thoroughly thrash out the international support in the language.








 there
 a good unicode text editor that supports Japanese?

Jan 12 2004

Georg Wrede <Georg_member pathlink.com> writes:

                        Hear, hear!!

I never program in Finnish either. And the only difference
would be about the same as for the Swedes, Germans, etc.,
which is just a few additional umaluts to ASCII. Never in
my wildest nightmares have I evere considered a variable
name with an umlaut! 

Also, since programming languages THEMSELVES are heavily based
on English, or at least the Western mind set, it would
be a travesty to pretend (or even worse, actually believe
oneself) that we're aiming for a programming language that is
"programmable in [any non-western origin language]".

The end result would only be the kind of mess Windows has
done to everybody by allowing spaces in file names. It's
hard to use Windows partitions in Unix, half of Windows
programs can't cope with spaces in paths, some of Windows itself
can't cope either. 

Or the mess of having all kinds of different dates and decimal
separators and stuff. Eg. I cannot enter decimals to most Windows
programs because the Finnish number pad contains a comma instead
of a point, and those programs still don't understand locales.

Or imagine someone writing field and table names with umlauts,
as I could today do in Access. I've seen people do it. And
within 24 months all of these people have had their ass kicked
so hard by "computers" that they'll never consider it again.
It's so pathetic to watch I never could say "I told you".

Entering times and dates is impossible in Excel, because Finland
uses the same separator (sic) for time and date. 30 years ago
there was an initiative in Europe to have only one format for date,
time, and decimals, but that became a fistfight. Eventually they
gave up, with the excuse "well, in just a couple of years computers
will be smart enough to blow this problem from existence". Ha!

And think about all the mistakes that will linger because it took
too long to fix them, and the no one anymore knows where they came
from, or why. An example: the Finnish and Swedish keyboards do not
have a $ sign. Instead you get a funny circle with four sprouts
sticking out. Ask anybody in Finland and they tell you it's because
the Swedes originally used it for something. My Swedish colleagues
tell me it's because it was needed for Finland. Since the '70s I
have never heard anybody explain why it is there. All it does is
make it impossible/hard (depending on the architecture) to type a
dollar sign.

Similar things should pop up in scores with all these Foreign
things. Suppose I want to program in a right-to left language?
How do I write a = b ? c : d in such an environment? How about
top-down written languages? Case in point: I can't even conjure
up an example! 

And of course you should be able to write parts of your program
in Hindi, others in old Chinese, and then paste American source
code here and there. (At this point some wiseguy posts a reply
stating that this is already solved. Look, this is only the tip
of the iceberg, trust me.)

Look at what tremendous advantages the entire world has  got from
everybody learning English, at least as a second language. Now
any two people can communicate without anybody needing more than
two languages total! (This pisses off the French, btw.) Heck, even
inside Finland it happens that talks are held in English by 
Swedish-speaking Finns for Finnish-only audiences because some
people don't understand Swedish. Look at India and some Far East
countries where everybody talks English. They're at an enormous
advantage to their neighbors.

What if the worst happened? That we'd succeed in making an easy
entry method for all kinds of languages, and then solve all these
Unicode programming issues? From that day on, humankind would start
taking steps back. Different people would become islands on the
vast Internet. They couldn't exchange source code, they could not
cooperate, no new Linux would ever emerge, they could not learn
from code written on the other side of the world. 

** Caveat reader, I'm all for having every possible language and
special character set _within quoted strings_, but that is 
different from actually programming in, say, Nepalese D. ***

Besides, merely allowing variable names in "foreignish" isn't 
really democratic, is it! We should go all the way (if we really
and truly want to run our heads into a concrete wall, that is).
Parentheses, operators and everything else should -- in the name
of equality and brotherhood -- also be writable in Foreignish!

If dates and such are still bothering us even here in Europe,
i bet it will take 150 years before all issues arising from
this misguided effort will have been smoothed out.

(( Now off to wipe the froth from my face and keyboard. ))

georg

In article <btutlc$2cvh$1 digitaldaemon.com>, davepermen says...
and i don't know why anyone should.. i think its the worst idea 
ever to allow unicode for coding.. who has a unicode keyboard? 
no one.. so typing itself gets stupid.

and the next.. what if linux would've been coded by the language 
of the developers? there we have finish, there we have french, 
there we have japanese, there we have swiss-german, there we 
have klingon, there we have raetoromantsch, there we have polish, 
etc..

how about staying in english?

i don't code in swiss-german eighter.. i'd never even thought 
about doing so.

this is the new babilon. its called internet.

oh and, i've seen quite some japanese (or so? i just see tons of 
squares:D) pages about D programming. i think its dissapointing, 
because they are rather good (as far as i can tell from the code), 
but i will never understand a word of it.

In article <btusbn$2ak3$1 digitaldaemon.com>, Robert says...
We need a few steps to input Japanese.
First, enter the pronunciation in Hiragana (a kind of Japanese characters).
Next, choise Kanji (Chinese characters) which is wanted now (this step isn't
needed to input Hiragana).
Last, press enter key to determine it.

So, the input cost is almost same or higher than that of the hybrid program.
i.e. input cost relation becomes:

since the Japanese aren't used to reading full-Japanese programs.
So, if I use Japanese identifiers, I will write hybrid programs.

 "Walter" <walter digitalmars.com> wrote in message
 Hi Robert! I'd actually prefer you wrote D in Japanese, as a way to help
 thoroughly thrash out the international support in the language. Isn't


 a good unicode text editor that supports Japanese?

Jan 12 2004

The Lone Haranguer <The_member pathlink.com> writes:

You've reminded me of when I took a trip to Germany in 1997, I tried to send an
email from an Internet cafe -- I couldn't find an "at sign" ( ) on the keyboard,
finally I pasted one from some website.

My main argument is that a programming language _is a language_. The word "if"
in D isn't English, it's D. And you can't change it without defining a new
language.

Now of course C went a long way toward using a lot of non-alphabetic characters
rather than "words", and perhaps that can be taken to its logical conclusion and
have no "keywords" in some language, yuck.

Another solution would be to go with something like the .Net languages and
compile to some intermediate language. And allow the IL to be decompiled into
your choice of dialect (as if).

In article <btv3hm$2n5q$1 digitaldaemon.com>, Georg Wrede says...
                        Hear, hear!!

I never program in Finnish either. And the only difference
would be about the same as for the Swedes, Germans, etc.,
which is just a few additional umaluts to ASCII. Never in
my wildest nightmares have I evere considered a variable
name with an umlaut! 

Also, since programming languages THEMSELVES are heavily based
on English, or at least the Western mind set, it would
be a travesty to pretend (or even worse, actually believe
oneself) that we're aiming for a programming language that is
"programmable in [any non-western origin language]".

The end result would only be the kind of mess Windows has
done to everybody by allowing spaces in file names. It's
hard to use Windows partitions in Unix, half of Windows
programs can't cope with spaces in paths, some of Windows itself
can't cope either. 


I wholeheartedly agree, Microsoft really screwed up with this.
But of course I'm a VMS guy and I think file names should be all caps and
contain at most one dot.

Jan 12 2004

"C" <dont respond.com> writes:

and perhaps that can be taken to its logical conclusion >and have no



See bf : http://www.muppetlabs.com/~breadbox/bf/ :)

C

"The Lone Haranguer" <The_member pathlink.com> wrote in message
news:btvqav$pqv$1 digitaldaemon.com...
 You've reminded me of when I took a trip to Germany in 1997, I tried to


 email from an Internet cafe -- I couldn't find an "at sign" ( ) on the


 finally I pasted one from some website.

 My main argument is that a programming language _is a language_. The word


 in D isn't English, it's D. And you can't change it without defining a new
 language.

 Now of course C went a long way toward using a lot of non-alphabetic


 rather than "words", and perhaps that can be taken to its logical


 have no "keywords" in some language, yuck.

 Another solution would be to go with something like the .Net languages and
 compile to some intermediate language. And allow the IL to be decompiled


 your choice of dialect (as if).

 In article <btv3hm$2n5q$1 digitaldaemon.com>, Georg Wrede says...
                        Hear, hear!!

I never program in Finnish either. And the only difference
would be about the same as for the Swedes, Germans, etc.,
which is just a few additional umaluts to ASCII. Never in
my wildest nightmares have I evere considered a variable
name with an umlaut!

Also, since programming languages THEMSELVES are heavily based
on English, or at least the Western mind set, it would
be a travesty to pretend (or even worse, actually believe
oneself) that we're aiming for a programming language that is
"programmable in [any non-western origin language]".

The end result would only be the kind of mess Windows has
done to everybody by allowing spaces in file names. It's
hard to use Windows partitions in Unix, half of Windows
programs can't cope with spaces in paths, some of Windows itself
can't cope either.


 I wholeheartedly agree, Microsoft really screwed up with this.
 But of course I'm a VMS guy and I think file names should be all caps and
 contain at most one dot.

Jan 12 2004

Andy Friesen <andy ikagames.com> writes:

C wrote:
and perhaps that can be taken to its logical conclusion >and have no


 "keywords" in some language, yuck.
 
 See bf : http://www.muppetlabs.com/~breadbox/bf/ :)
 
 C


BF is really interesting.  It's the ultimate simplification of a 
programming language.

If you want evil, K is about as frightening as a real (as in actually 
useful) programming language gets: 
<http://www.kuro5hin.org/story/2002/11/14/22741/791>

Malbolge takes the next logical step, claiming the crown of nastiest 
programming language ever concieved (let alone implemented): 
<http://www.mines.edu/students/b/bolmstea/malbolge/>.

(the latter of which features a single trinary operation that's more or 
less an arbitrary trit transposition)

  -- andy

Jan 12 2004

"C" <dont respond.com> writes:

Thats cool I remember seeing K on kuroshin and thinking Id like to learn it
, never got around to it though.  Maybe Ill give it a second go.

C

"Andy Friesen" <andy ikagames.com> wrote in message
news:btvrn8$s1l$1 digitaldaemon.com...
 C wrote:
and perhaps that can be taken to its logical conclusion >and have no


 "keywords" in some language, yuck.

 See bf : http://www.muppetlabs.com/~breadbox/bf/ :)

 C


 BF is really interesting.  It's the ultimate simplification of a
 programming language.

 If you want evil, K is about as frightening as a real (as in actually
 useful) programming language gets:
 <http://www.kuro5hin.org/story/2002/11/14/22741/791>

 Malbolge takes the next logical step, claiming the crown of nastiest
 programming language ever concieved (let alone implemented):
 <http://www.mines.edu/students/b/bolmstea/malbolge/>.

 (the latter of which features a single trinary operation that's more or
 less an arbitrary trit transposition)

   -- andy

Jan 13 2004

"Robert" <no spam.ne.jp> writes:

Whitespace is the funniest language I've ever seen.  :)
http://compsoc.dur.ac.uk/whitespace/


"Andy Friesen" <andy ikagames.com> wrote in message
news:btvrn8$s1l$1 digitaldaemon.com...
 C wrote:
and perhaps that can be taken to its logical conclusion >and have no


 "keywords" in some language, yuck.

 See bf : http://www.muppetlabs.com/~breadbox/bf/ :)

 C


 BF is really interesting.  It's the ultimate simplification of a
 programming language.

 If you want evil, K is about as frightening as a real (as in actually
 useful) programming language gets:
 <http://www.kuro5hin.org/story/2002/11/14/22741/791>

 Malbolge takes the next logical step, claiming the crown of nastiest
 programming language ever concieved (let alone implemented):
 <http://www.mines.edu/students/b/bolmstea/malbolge/>.

 (the latter of which features a single trinary operation that's more or
 less an arbitrary trit transposition)

   -- andy

Jan 13 2004

"C" <dont respond.com> writes:

lol!

on an OT : Im going to make DIDE unicode mainly for the use in Japan.  Im
going to add an option to set the code page to Shift-JIS , but I've never
written a unicode app before.  I'm using MFC , should i leave the MBCS ,
change everything to wchar_t ( wstring, wifstream ) , or do i need do define
UNICODE  ?

Thanks, sorry for the ignorance :S.

C
"Robert" <no spam.ne.jp> wrote in message
news:bu14ed$3090$1 digitaldaemon.com...
 Whitespace is the funniest language I've ever seen.  :)
 http://compsoc.dur.ac.uk/whitespace/


 "Andy Friesen" <andy ikagames.com> wrote in message
 news:btvrn8$s1l$1 digitaldaemon.com...
 C wrote:
and perhaps that can be taken to its logical conclusion >and have no


 "keywords" in some language, yuck.

 See bf : http://www.muppetlabs.com/~breadbox/bf/ :)

 C


 BF is really interesting.  It's the ultimate simplification of a
 programming language.

 If you want evil, K is about as frightening as a real (as in actually
 useful) programming language gets:
 <http://www.kuro5hin.org/story/2002/11/14/22741/791>

 Malbolge takes the next logical step, claiming the crown of nastiest
 programming language ever concieved (let alone implemented):
 <http://www.mines.edu/students/b/bolmstea/malbolge/>.

 (the latter of which features a single trinary operation that's more or
 less an arbitrary trit transposition)

   -- andy

Jan 13 2004

"C" <dont respond.com> writes:

Just a revision ( im still reading , seems like theres alot of stuff to do
with unicode, looks like a nightmare! ).

Ill be defining _UNICODE and UNICODE, and using TCHAR'ed STL ( see
attached ) but there are some things I dont understand and have no way to
confirm other than asking.

Apparently there are 4 charater sets ( Kanji, Hiragana, Katakana, and Romaji
? ) and I'm not sure how that relates to the whole thing , and what does
Shift-JIS use ?.  And does a japanese system use native charater sets for
filenames ?  is their a C:\  and similar partiions, or is that renamed ?
And apparently tofstream ( the TCHAR version ) does NOT create unicode files
, that needs some sort of header (  0xFEFF ? )?  Without will the app
explode ?  Does using TCHAR mean that the file name will correctly display
in the ListBox ?  Ill keep reading any help u can offer is aprreciated.

C[lueless]



"C" <dont respond.com> wrote in message
news:bu1gbo$kbp$1 digitaldaemon.com...
 lol!

 on an OT : Im going to make DIDE unicode mainly for the use in Japan.  Im
 going to add an option to set the code page to Shift-JIS , but I've never
 written a unicode app before.  I'm using MFC , should i leave the MBCS ,
 change everything to wchar_t ( wstring, wifstream ) , or do i need do


 UNICODE  ?

 Thanks, sorry for the ignorance :S.

 C
 "Robert" <no spam.ne.jp> wrote in message
 news:bu14ed$3090$1 digitaldaemon.com...
 Whitespace is the funniest language I've ever seen.  :)
 http://compsoc.dur.ac.uk/whitespace/


 "Andy Friesen" <andy ikagames.com> wrote in message
 news:btvrn8$s1l$1 digitaldaemon.com...
 C wrote:
and perhaps that can be taken to its logical conclusion >and have no


 "keywords" in some language, yuck.

 See bf : http://www.muppetlabs.com/~breadbox/bf/ :)

 C


 BF is really interesting.  It's the ultimate simplification of a
 programming language.

 If you want evil, K is about as frightening as a real (as in actually
 useful) programming language gets:
 <http://www.kuro5hin.org/story/2002/11/14/22741/791>

 Malbolge takes the next logical step, claiming the crown of nastiest
 programming language ever concieved (let alone implemented):
 <http://www.mines.edu/students/b/bolmstea/malbolge/>.

 (the latter of which features a single trinary operation that's more






 less an arbitrary trit transposition)

   -- andy

Jan 13 2004

"Robert" <no spam.ne.jp> writes:

 Syntax of Shift-JIS



One-byte character set:
    ASCII code   : 0x00-0x7F
    Hankaku-Kana : 0xA0-0xDF

Two-byte character set:
    First byte  : 0x81-0xFC
    Second byte : 0x40-0xFC except 0x7F

For example, x"44 20 82CC 835C 815B 8358 82CC 955C 8B4C 9640" is a valid
Shift-JIS string.
(Note that 835C and 955C include the same codes as backslash (5C) at the
second bytes.


 Relation between Unicode and Shift-JIS


So, the conversion is not simple if implementing whole by oneself.
These can be converted each other through
MultiByteToWideChar/WideCharToMultiByte APIs,
or mbstowcs/wcstombs functions.


 Filenames in Japanese


Note that second byte of some two-byte characters is backslash,
but it is NOT taken as a separator of directory names.


 that needs some sort of header (  0xFEFF ? )?


See: http://www.digitalmars.com/d/lex.html


 tofstream ( the TCHAR version ) does NOT create unicode files


Perhaps it is correct, but I'm not sure...
Maybe using CFile and writing unicode strings with .Write method is better.


 TCHAR, WinAPIs, and _tcs functions


_UNICODE macros.
They are important things, but it is not a way to handle unicode text.
They are only for switching 'A'/'W' APIs and 'str'/'_mbs'/'_wcs' functions
depending on the environment.

To handle MBCS or unicode text directly,
char/wchar_t, 'A'/'W' APIs or '_mbs'/'_wcs' functions should be used
directly, too,.



"C" <dont respond.com> wrote in message
news:bu1psv$14ne$1 digitaldaemon.com...
 Just a revision ( im still reading , seems like theres alot of stuff to do
 with unicode, looks like a nightmare! ).

 Ill be defining _UNICODE and UNICODE, and using TCHAR'ed STL ( see
 attached ) but there are some things I dont understand and have no way to
 confirm other than asking.

 Apparently there are 4 charater sets ( Kanji, Hiragana, Katakana, and


 ? ) and I'm not sure how that relates to the whole thing , and what does
 Shift-JIS use ?.  And does a japanese system use native charater sets for
 filenames ?  is their a C:\  and similar partiions, or is that renamed ?
 And apparently tofstream ( the TCHAR version ) does NOT create unicode


 , that needs some sort of header (  0xFEFF ? )?  Without will the app
 explode ?  Does using TCHAR mean that the file name will correctly display
 in the ListBox ?  Ill keep reading any help u can offer is aprreciated.

 C[lueless]



 "C" <dont respond.com> wrote in message
 news:bu1gbo$kbp$1 digitaldaemon.com...
 lol!

 on an OT : Im going to make DIDE unicode mainly for the use in Japan.




 going to add an option to set the code page to Shift-JIS , but I've




 written a unicode app before.  I'm using MFC , should i leave the MBCS ,
 change everything to wchar_t ( wstring, wifstream ) , or do i need do


 UNICODE  ?

 Thanks, sorry for the ignorance :S.

 C

Jan 14 2004

Matthias Becker <Matthias_member pathlink.com> writes:

You've reminded me of when I took a trip to Germany in 1997, I tried to send an
email from an Internet cafe -- I couldn't find an "at sign" ( ) on the keyboard,
finally I pasted one from some website.


For the feature: It's the same key as Q, but you hvae to hold Alt Gr while
pressing it. Using Alt Gr you can access even more symbols. Alt Gr+M = �, Alt
Gr+< = | ...

Jan 15 2004

"Lars Ivar Igesund" <larsivar igesund.net> writes:

"Georg Wrede" <Georg_member pathlink.com> wrote in message
news:btv3hm$2n5q$1 digitaldaemon.com...
 Entering times and dates is impossible in Excel, because Finland
 uses the same separator (sic) for time and date. 30 years ago
 there was an initiative in Europe to have only one format for date,
 time, and decimals, but that became a fistfight. Eventually they
 gave up, with the excuse "well, in just a couple of years computers
 will be smart enough to blow this problem from existence". Ha!


In Norway, the function names in Excel are translated to Norwegian,
making the sheets impossible to use elsewhere...

Lars Ivar Igesund

Jan 13 2004

=?iso-8859-1?Q?=22Robert_M._M=FCnch=22?= <robert.muench robertmuench.de> writes:

On Tue, 13 Jan 2004 10:27:45 +0100, Lars Ivar Igesund 
<larsivar igesund.net> wrote:

 In Norway, the function names in Excel are translated to Norwegian,
 making the sheets impossible to use elsewhere...


Same for German, that's the most stupid thing I have ever seen. It would 
be OK if the english version would work in a shadow way... but hey, it's 
MS the 50% company.

-- 
Robert M. M�nch
Management & IT Freelancer
http://www.robertmuench.de

Jan 15 2004

ssuukk <ssuukk .go2.pl> writes:

 
 Same for German, that's the most stupid thing I have ever seen. It would 
 be OK if the english version would work in a shadow way... but hey, it's 
 MS the 50% company.

Jan 15 2004

"Walter" <walter digitalmars.com> writes:

"davepermen" <davepermen_member pathlink.com> wrote in message
news:btutlc$2cvh$1 digitaldaemon.com...
 and the next.. what if linux would've been coded by the language of the
 developers? there we have finish, there we have french, there we have


 there we have swiss-german, there we have klingon, there we have


 there we have polish, etc..

 how about staying in english?


The need to support international characters in strings is clear, and in
comments as well. For identifiers, it's arguable. But it's easy enough to
make it work in D, and many people want it.

Jan 16 2004

davepermen <davepermen_member pathlink.com> writes:

even for comments, i don't agree. we have a product at work on wich our company
system bases on. and its been written in the netherlands. just guess how good we
are at reading netherlandish comments in switzerland?!

espencially a word read like it would mean dismiss in german actually means
accept. rather irritating:P

no. you should always code in english. its todays babilon-language. just as
latin was a while ago.

In article <bu9lcu$1vps$1 digitaldaemon.com>, Walter says...
"davepermen" <davepermen_member pathlink.com> wrote in message
news:btutlc$2cvh$1 digitaldaemon.com...
 and the next.. what if linux would've been coded by the language of the
 developers? there we have finish, there we have french, there we have


 there we have swiss-german, there we have klingon, there we have


 there we have polish, etc..

 how about staying in english?


The need to support international characters in strings is clear, and in
comments as well. For identifiers, it's arguable. But it's easy enough to
make it work in D, and many people want it.

Jan 16 2004

"Robert" <no spam.ne.jp> writes:

I don't agree.
Indeed, English comments may need in Europa.
But IMHO you'd better write it also in your own language,
especially for long comments.
Because at least the persons who use the language can read it
and they are easier to read it than English comments.
And more, some persons will write wrong English.
Wrong comments are very evil...
If they are written in two languages,
someone can check it.

And, should we use english for comments in private programming?
Should we use it when nobody else Japanese reads it.
I think It's nonsense.



"davepermen" <davepermen_member pathlink.com> wrote in message
news:bua0t9$2i5r$1 digitaldaemon.com...
 even for comments, i don't agree. we have a product at work on wich our


 system bases on. and its been written in the netherlands. just guess how


 are at reading netherlandish comments in switzerland?!

 espencially a word read like it would mean dismiss in german actually


 accept. rather irritating:P

 no. you should always code in english. its todays babilon-language. just


 latin was a while ago.

 In article <bu9lcu$1vps$1 digitaldaemon.com>, Walter says...
"davepermen" <davepermen_member pathlink.com> wrote in message
news:btutlc$2cvh$1 digitaldaemon.com...
 and the next.. what if linux would've been coded by the language of the
 developers? there we have finish, there we have french, there we have


 there we have swiss-german, there we have klingon, there we have


 there we have polish, etc..

 how about staying in english?


The need to support international characters in strings is clear, and in
comments as well. For identifiers, it's arguable. But it's easy enough to
make it work in D, and many people want it.

Jan 16 2004

"Matthew" <matthew.hat stlsoft.dot.org> writes:

I'm in the Kernighan/Pike/Dewhurst/etc camp that say that comments are often
unnecessary and are, by and large, misused.

Given that D supports DbC as a language feature, and that most people are
happy writing auto-documentation in their code, is there much need for
comments in the code itself?

I'd be interested in seeing some examples from you both, demonstrating your
points of view.



"Robert" <no spam.ne.jp> wrote in message
news:buaq0f$s4l$1 digitaldaemon.com...
 I don't agree.
 Indeed, English comments may need in Europa.
 But IMHO you'd better write it also in your own language,
 especially for long comments.
 Because at least the persons who use the language can read it
 and they are easier to read it than English comments.
 And more, some persons will write wrong English.
 Wrong comments are very evil...
 If they are written in two languages,
 someone can check it.

 And, should we use english for comments in private programming?
 Should we use it when nobody else Japanese reads it.
 I think It's nonsense.



 "davepermen" <davepermen_member pathlink.com> wrote in message
 news:bua0t9$2i5r$1 digitaldaemon.com...
 even for comments, i don't agree. we have a product at work on wich our


 system bases on. and its been written in the netherlands. just guess how


 are at reading netherlandish comments in switzerland?!

 espencially a word read like it would mean dismiss in german actually


 accept. rather irritating:P

 no. you should always code in english. its todays babilon-language. just


 latin was a while ago.

 In article <bu9lcu$1vps$1 digitaldaemon.com>, Walter says...
"davepermen" <davepermen_member pathlink.com> wrote in message
news:btutlc$2cvh$1 digitaldaemon.com...
 and the next.. what if linux would've been coded by the language of








 developers? there we have finish, there we have french, there we have


 there we have swiss-german, there we have klingon, there we have


 there we have polish, etc..

 how about staying in english?


The need to support international characters in strings is clear, and






comments as well. For identifiers, it's arguable. But it's easy enough






make it work in D, and many people want it.

Jan 17 2004

Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

IMHO, dbc tells you "what," and comments tell you "why."

That is, dbc tells you what you expect at any given point in the 
program.  It tells you what is a bug and what is normal.  But it doesn't 
tell you why it is a bug.  Comments explain the algorithm in (hopefully) 
clearer terms than the code itself does.  Comments also help communicate 
non-obvious side effects in your program.  For example, you might see 
something like this:

	assert(enumVar == FOO || enumVar == BAR);
		/* myFunc() (foo/bar/myfunc.d) sets these values and
		 * ensures that no other values are possible */

So the assert() defines the interface, but the comment tells you why the 
interface makes sense.

Russ Lewis

Matthew wrote:
 I'm in the Kernighan/Pike/Dewhurst/etc camp that say that comments are often
 unnecessary and are, by and large, misused.
 
 Given that D supports DbC as a language feature, and that most people are
 happy writing auto-documentation in their code, is there much need for
 comments in the code itself?
 
 I'd be interested in seeing some examples from you both, demonstrating your
 points of view.
 
 
 
 "Robert" <no spam.ne.jp> wrote in message
 news:buaq0f$s4l$1 digitaldaemon.com...
 
I don't agree.
Indeed, English comments may need in Europa.
But IMHO you'd better write it also in your own language,
especially for long comments.
Because at least the persons who use the language can read it
and they are easier to read it than English comments.
And more, some persons will write wrong English.
Wrong comments are very evil...
If they are written in two languages,
someone can check it.

And, should we use english for comments in private programming?
Should we use it when nobody else Japanese reads it.
I think It's nonsense.



"davepermen" <davepermen_member pathlink.com> wrote in message
news:bua0t9$2i5r$1 digitaldaemon.com...

even for comments, i don't agree. we have a product at work on wich our


company

system bases on. and its been written in the netherlands. just guess how


good we

are at reading netherlandish comments in switzerland?!

espencially a word read like it would mean dismiss in german actually


means

accept. rather irritating:P

no. you should always code in english. its todays babilon-language. just


as

latin was a while ago.

In article <bu9lcu$1vps$1 digitaldaemon.com>, Walter says...

"davepermen" <davepermen_member pathlink.com> wrote in message
news:btutlc$2cvh$1 digitaldaemon.com...

and the next.. what if linux would've been coded by the language of








 the
 
developers? there we have finish, there we have french, there we have


japanese,

there we have swiss-german, there we have klingon, there we have


raetoromantsch,

there we have polish, etc..

how about staying in english?


The need to support international characters in strings is clear, and






 in
 
comments as well. For identifiers, it's arguable. But it's easy enough






 to
 
make it work in D, and many people want it.

Jan 20 2004

"Matthew" <matthew.hat stlsoft.dot.org> writes:

In many cases you can include the why in the comment, as in:

    string_tokeniser(char_type const *psz, delimiter_type const &delimiter)
        : m_str(psz)
        , m_delimiter(delimiter)
    {
        stlsoft_message_assert("Delimiter of zero-length",
comparator_type::length(m_delimiter) > 0);
    }


"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:bujp5j$7ta$1 digitaldaemon.com...
 IMHO, dbc tells you "what," and comments tell you "why."

 That is, dbc tells you what you expect at any given point in the
 program.  It tells you what is a bug and what is normal.  But it doesn't
 tell you why it is a bug.  Comments explain the algorithm in (hopefully)
 clearer terms than the code itself does.  Comments also help communicate
 non-obvious side effects in your program.  For example, you might see
 something like this:

 assert(enumVar == FOO || enumVar == BAR);
 /* myFunc() (foo/bar/myfunc.d) sets these values and
 * ensures that no other values are possible */

 So the assert() defines the interface, but the comment tells you why the
 interface makes sense.

 Russ Lewis

 Matthew wrote:
 I'm in the Kernighan/Pike/Dewhurst/etc camp that say that comments are




 unnecessary and are, by and large, misused.

 Given that D supports DbC as a language feature, and that most people




 happy writing auto-documentation in their code, is there much need for
 comments in the code itself?

 I'd be interested in seeing some examples from you both, demonstrating




 points of view.



 "Robert" <no spam.ne.jp> wrote in message
 news:buaq0f$s4l$1 digitaldaemon.com...

I don't agree.
Indeed, English comments may need in Europa.
But IMHO you'd better write it also in your own language,
especially for long comments.
Because at least the persons who use the language can read it
and they are easier to read it than English comments.
And more, some persons will write wrong English.
Wrong comments are very evil...
If they are written in two languages,
someone can check it.

And, should we use english for comments in private programming?
Should we use it when nobody else Japanese reads it.
I think It's nonsense.



"davepermen" <davepermen_member pathlink.com> wrote in message
news:bua0t9$2i5r$1 digitaldaemon.com...

even for comments, i don't agree. we have a product at work on wich our


company

system bases on. and its been written in the netherlands. just guess








good we

are at reading netherlandish comments in switzerland?!

espencially a word read like it would mean dismiss in german actually


means

accept. rather irritating:P

no. you should always code in english. its todays babilon-language.








as

latin was a while ago.

In article <bu9lcu$1vps$1 digitaldaemon.com>, Walter says...

"davepermen" <davepermen_member pathlink.com> wrote in message
news:btutlc$2cvh$1 digitaldaemon.com...

and the next.. what if linux would've been coded by the language of








 the

developers? there we have finish, there we have french, there we have


japanese,

there we have swiss-german, there we have klingon, there we have


raetoromantsch,

there we have polish, etc..

how about staying in english?


The need to support international characters in strings is clear, and






 in

comments as well. For identifiers, it's arguable. But it's easy enough






 to

make it work in D, and many people want it.

Jan 20 2004

Georg Wrede <Georg_member pathlink.com> writes:

In article <buk3ar$nrn$1 digitaldaemon.com>, Matthew says...
In many cases you can include the why in the comment, as in:
        stlsoft_message_assert("Delimiter of zero-length",
comparator_type::length(m_delimiter) > 0);


In most cases you _should_!

Jan 20 2004

davepermen <davepermen_member pathlink.com> writes:

as matthew stated, too, there isn't much need in real comments.

and yes, i code 100% in english. and english is my 4th language actually.

even at home, private stuff.

coding should be in a language about everyone understands. about everyone
capable of coding understands english.

what if i'd ask you to send me some of your private code.. say you have a
function i'd like to use. you send it to me, and it's in japanese. then i
realise, i should modify it a bit. will get rather difficult.

no. you should code in english. and you should never comment except if it's
needed. wich is about never :P

In article <buaq0f$s4l$1 digitaldaemon.com>, Robert says...
I don't agree.
Indeed, English comments may need in Europa.
But IMHO you'd better write it also in your own language,
especially for long comments.
Because at least the persons who use the language can read it
and they are easier to read it than English comments.
And more, some persons will write wrong English.
Wrong comments are very evil...
If they are written in two languages,
someone can check it.

And, should we use english for comments in private programming?
Should we use it when nobody else Japanese reads it.
I think It's nonsense.



"davepermen" <davepermen_member pathlink.com> wrote in message
news:bua0t9$2i5r$1 digitaldaemon.com...
 even for comments, i don't agree. we have a product at work on wich our


 system bases on. and its been written in the netherlands. just guess how


 are at reading netherlandish comments in switzerland?!

 espencially a word read like it would mean dismiss in german actually


 accept. rather irritating:P

 no. you should always code in english. its todays babilon-language. just


 latin was a while ago.

 In article <bu9lcu$1vps$1 digitaldaemon.com>, Walter says...
"davepermen" <davepermen_member pathlink.com> wrote in message
news:btutlc$2cvh$1 digitaldaemon.com...
 and the next.. what if linux would've been coded by the language of the
 developers? there we have finish, there we have french, there we have


 there we have swiss-german, there we have klingon, there we have


 there we have polish, etc..

 how about staying in english?


The need to support international characters in strings is clear, and in
comments as well. For identifiers, it's arguable. But it's easy enough to
make it work in D, and many people want it.

Jan 18 2004

J Anderson <REMOVEanderson badmama.com.au> writes:

davepermen wrote:

as matthew stated, too, there isn't much need in real comments.

and yes, i code 100% in english. and english is my 4th language actually.

even at home, private stuff.

coding should be in a language about everyone understands. about everyone
capable of coding understands english.

what if i'd ask you to send me some of your private code.. say you have a
function i'd like to use. you send it to me, and it's in japanese. then i
realise, i should modify it a bit. will get rather difficult.

no. you should code in english. and you should never comment except if it's
needed. wich is about never :P

  


no. you should code in english. 



Here's a rant about this issue.
http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=16664


I disagree, that's like saying everybody should speak English.  You need to be
able to code in a way that has meaning to yourself.  If your coding for the
main stream, then of course make the visible interface English but the
inner-workings, variable names ect... use what every makes the most sense to
you and your team (and potential maintainers)..

-Anderson

Jan 18 2004

qw <qw_member pathlink.com> writes:

In article <budqgj$2oei$1 digitaldaemon.com>, davepermen says...

coding should be in a language about everyone understands. about everyone
capable of coding understands english.

what if i'd ask you to send me some of your private code.. say you have a
function i'd like to use. you send it to me, and it's in japanese. then i
realise, i should modify it a bit. will get rather difficult.

no. you should code in english. and you should never comment except if it's
needed. wich is about never :P


If comments are unnecessary for you, you could simply ignore the japanese
comments (or strip them) and read only the code... Everyone is happy. I don't
think the compiler should check for invalid characters in comments (same for
strings). What if I want to put a class diagrams in a comment... (cool idea for
an advanced IDE)

Jan 18 2004

J Anderson <REMOVEanderson badmama.com.au> writes:

qw wrote:

What if I want to put a class diagrams in a comment... (cool idea for
an advanced IDE)
  


Yeah, I can't wait to to HTML documents come part of the D IDE's

Jan 18 2004

Ant <Ant_member pathlink.com> writes:

In article <buebn8$h7d$1 digitaldaemon.com>, qw says...
What if I want to put a class diagrams in a comment... (cool idea for
an advanced IDE)


Cool idea, yes.
But an advance IDE will have a better way
that a static comment ;)

Ant

Jan 18 2004

Georg Wrede <Georg_member pathlink.com> writes:

In article <bueds2$kdo$1 digitaldaemon.com>, Ant says...
In article <buebn8$h7d$1 digitaldaemon.com>, qw says...
What if I want to put a class diagrams in a comment... (cool idea for
an advanced IDE)


Cool idea, yes.
But an advance IDE will have a better way
that a static comment ;)


Who needs an IDE? You can always create and edit your D
programs with Netscape web page editor. Put in any diagrams
and text inbetween your code. Then compile as usual:

dmd mywebpage.html

For more info, see  http://www.digitalmars.com/d/html.html

Jan 18 2004

J Anderson <REMOVEanderson badmama.com.au> writes:

Georg Wrede wrote:

In article <bueds2$kdo$1 digitaldaemon.com>, Ant says...
  

In article <buebn8$h7d$1 digitaldaemon.com>, qw says...
    

What if I want to put a class diagrams in a comment... (cool idea for
an advanced IDE)

      


But an advance IDE will have a better way
that a static comment ;)
    


Who needs an IDE? You can always create and edit your D
programs with Netscape web page editor. Put in any diagrams
and text inbetween your code. Then compile as usual:

dmd mywebpage.html

For more info, see  http://www.digitalmars.com/d/html.html

  


meaning that you would need to maitain two copies of the code.

-Anderson

Jan 18 2004

Georg Wrede <Georg_member pathlink.com> writes:

The problem here is that you can't currently use HTML d code in a d IDE, 
meaning that you would need to maitain two copies of the code.


How about making <code> equivalent with +/ and </code> with /+
in the editor, as a first step. Second step would be to let the
user view or not view what's outside the code tags. Third step
would be to add an html viewer to the code window as a tab?

(Just some crazy ideas...)

Jan 18 2004

J Anderson <REMOVEanderson badmama.com.au> writes:

Georg Wrede wrote:

The problem here is that you can't currently use HTML d code in a d IDE, 
meaning that you would need to maitain two copies of the code.
    


How about making <code> equivalent with +/ and </code> with /+
in the editor, as a first step. Second step would be to let the
user view or not view what's outside the code tags. Third step
would be to add an html viewer to the code window as a tab?

(Just some crazy ideas...)

  


tags in code ie the obvious ones would be <b><i><u> <img>. But that does 
seem allot of work considering how many html tags there are.  I wonder 
if there's a free richtextbox-like-html control out there? Parhaps 
Mozilla Composer could be used as an active X object or something like that.

Jan 18 2004

Matthias Becker <Matthias_member pathlink.com> writes:

I don't like both versions. What about a simpler notation easy to learn for
newbees? Somthing like this:

Foo foo = bar as Foo;


(This would be the same as
Foo foo = cast(Foo)bar;
)

Jan 15 2004

Ant <Ant_member pathlink.com> writes:

In article <bu67e4$27q7$1 digitaldaemon.com>, Matthias Becker says...
I don't like both versions. What about a simpler notation easy to learn for
newbees? Somthing like this:

Foo foo = bar as Foo;


(This would be the same as
Foo foo = cast(Foo)bar;
)


what don't you like (can't get previous message)?

did you see the
Foo foo = bar.castTo(Foo) or
suggestion?

This would be the same as...
well is so obvious that I don't have to explain it.

Ant

Jan 15 2004

Lewis <dethbomb hotmail.com> writes:

Matthias Becker wrote:

 I don't like both versions. What about a simpler notation easy to learn for
 newbees? Somthing like this:
 
 Foo foo = bar as Foo;
 
 
 (This would be the same as
 Foo foo = cast(Foo)bar;
 )
 
 


two ways of doing something is the most confusing thing for newbs (speaking
from 
experience), especially when looking at other source code, Make one good way an 
keep that, is the best thing in my opinion.
Regards
Lewis

Jan 15 2004

Matthias Becker <Matthias_member pathlink.com> writes:

In article <bu697k$2aqj$1 digitaldaemon.com>, Lewis says...
Matthias Becker wrote:

 I don't like both versions. What about a simpler notation easy to learn for
 newbees? Somthing like this:
 
 Foo foo = bar as Foo;
 
 
 (This would be the same as
 Foo foo = cast(Foo)bar;
 )
 
 


two ways of doing something is the most confusing thing for newbs (speaking
from 
experience), especially when looking at other source code, Make one good way an 
keep that, is the best thing in my opinion.
Regards
Lewis


So let's kick of the old notaion. D still hasn't reached version 1.0, so it's
possible to change the language rather than just extending it.


About the notation

Foo foo = bar.cast_to(Foo);

In C++ you'd do it like this:

class Bar {
public:
template <typename T>
T cast_to ()
{
return static_cast<T>(*this);
}
};

But as D doesn't support non-static member-templates this isn't possible. As
said: C++ is more powerfull than D. I hope this will change till version 1.0, as
many aspects of D are realy cool.

Jan 15 2004

Ant <Ant_member pathlink.com> writes:

In article <bu6bd0$2efj$1 digitaldaemon.com>, Matthias Becker says...
So let's kick of the old notaion.


It's a must ;)

About the notation

Foo foo = bar.cast_to(Foo);


Every body knows that "_" is uggly.

I see "_" used for low level things only,
not any public symbols.

This is not a new discussion.
Walter noticed this before but I think his last
comment was that he didn't see any real advantage.

The only advantage I see is readability.
if you didn't see the previous discution here it is:

the current:
(cast(ClassB)(cast(ClassA)getIt()).getOther()).printIt()
(i don't even know if it's right)
the proposed:
getIt().castTo(ClassA).getOther().castTo(ClassB).printIt()

for the current version:
cast(Foo)bar where the "cast" is optional
the advantage is compatibility with older languages.

Ant

Jan 15 2004

Lewis <dethbomb hotmail.com> writes:

Ant wrote:
 In article <bu6bd0$2efj$1 digitaldaemon.com>, Matthias Becker says...
 
So let's kick of the old notaion.


 
 It's a must ;)
 
 
About the notation

Foo foo = bar.cast_to(Foo);


 
 Every body knows that "_" is uggly.
 
 I see "_" used for low level things only,
 not any public symbols.
 
 This is not a new discussion.
 Walter noticed this before but I think his last
 comment was that he didn't see any real advantage.
 
 The only advantage I see is readability.
 if you didn't see the previous discution here it is:
 
 the current:
 (cast(ClassB)(cast(ClassA)getIt()).getOther()).printIt()
 (i don't even know if it's right)
 the proposed:
 getIt().castTo(ClassA).getOther().castTo(ClassB).printIt()
 
 for the current version:
 cast(Foo)bar where the "cast" is optional
 the advantage is compatibility with older languages.
 
 Ant

Jan 15 2004

"Robert" <no spam.ne.jp> writes:

"Ant" <Ant_member pathlink.com> wrote in message
news:bu6dpm$2imd$1 digitaldaemon.com...
 In article <bu6bd0$2efj$1 digitaldaemon.com>, Matthias Becker says...
So let's kick of the old notaion.


 It's a must ;)

About the notation

Foo foo = bar.cast_to(Foo);


 Every body knows that "_" is uggly.

 I see "_" used for low level things only,
 not any public symbols.

 This is not a new discussion.
 Walter noticed this before but I think his last
 comment was that he didn't see any real advantage.

 The only advantage I see is readability.
 if you didn't see the previous discution here it is:

 the current:
 (cast(ClassB)(cast(ClassA)getIt()).getOther()).printIt()
 (i don't even know if it's right)
 the proposed:
 getIt().castTo(ClassA).getOther().castTo(ClassB).printIt()

 for the current version:
 cast(Foo)bar where the "cast" is optional
 the advantage is compatibility with older languages.

 Ant


I like the postfix cast, but above code is not realistic IMO...

Postfix cast is a quite new syntax for D,
so I think that it may not be implemented
unless it has a great number of merits
or it is easy to be implemented.

If member function templates are supported,

    class A {
        template castTo(T : A) {
            T castTo() {
                return cast(T) this;
            }
        }
    }

    class B : A { }

    A b = new B;
    b.castTo!(B)

gives a postfix cast.
i.e. postfix casts can be implemented as property templates.
So, if property templates are supported,
postfix casts may be easy to be implemented.
Then it will be time to request the postfix casts to Walter...

Jan 15 2004

Matthias Becker <Matthias_member pathlink.com> writes:

This all hasn't changed my mind. The 'as' is still my favorit.

String text = message as String;

This looks very natural and intuitiv to me.

Jan 16 2004

"Matthew" <matthew.hat stlsoft.dot.org> writes:

I don't know if anyone's addressed the point yet, but I think it's important
to note how well, and how easily, it is to provide user-defined casts in C++
that fit into the normal syntax. I recently had occasion to ask BS whether
he'd anticipated that when he created the template syntax, and he observed
that it might have crossed his mind ;)

We should have the same facility in D. Not being enough of a D templatist
yet, I can't say exactly how it should look, but I think we would be foolish
to not avail ourselves of the same power and expressiveness as C++ in this
regard.

Walter, since you're the BS of D, do you have any thoughts on this?


"Matthias Becker" <Matthias_member pathlink.com> wrote in message
news:bu8g1u$1q3$1 digitaldaemon.com...
 This all hasn't changed my mind. The 'as' is still my favorit.

 String text = message as String;

 This looks very natural and intuitiv to me.

Jan 16 2004

D Programming

C/C++ Programming

Other

D - suggestion for cast expression