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)

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)

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)

"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?

"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
there
> 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? http://www.digitalmars.com/drn-bin/wwwnews?D/19978

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
there
> a good unicode text editor that supports Japanese?

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
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?
>
>

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
>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?
>>
>>
>

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
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
> >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?
> >>
> >>
> >
>
>

                        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
>>> there
>>> > a good unicode text editor that supports Japanese?