One of basic aims is to achieve good comprehensibility code. It should look
as clear as possible. So why not use characters from 2200-22FF (unicode) as
operators? Good programming language should offer free use of such symbols.
For example: any collection should provide 220A operator as it means simply
"belogns to".
 I see no reason for omtting such an obvious improvement!
Of course you will tell me, there are people using ASCII set. But when they
see nice new "in" operator, they will qiuckly switch to unicode.
 I see, my idea looks like a joke at this moment. Just try to imagine code
using some easy-readable mathematical notations! Compact and clean.
 I believe there will appear in future an operation that will cause all
programmers wondering if they can overload some operator made of special
symbol. Do you want to have to extend D any time there emerge new concept?
Dawid

"Dawid Toton" <dad@o2.pl> wrote in message news:cv04a2$pjj$1@digitaldaemon.com...
> One of basic aims is to achieve good comprehensibility code. It should
> look
> as clear as possible. So why not use characters from 2200-22FF (unicode)
> as
> operators? Good programming language should offer free use of such
> symbols.
> For example: any collection should provide 220A operator as it means
> simply
> "belogns to".
> I see no reason for omtting such an obvious improvement!
> Of course you will tell me, there are people using ASCII set. But when
> they
> see nice new "in" operator, they will qiuckly switch to unicode.
> I see, my idea looks like a joke at this moment. Just try to imagine code
> using some easy-readable mathematical notations! Compact and clean.
> I believe there will appear in future an operation that will cause all
> programmers wondering if they can overload some operator made of special
> symbol. Do you want to have to extend D any time there emerge new concept?
> Dawid
>

I like the unicode idea, but I think that would be difficult to pull off. However, you wouldn't even have to move to 16-bit chars to realize an improvement.  You could simply utilize all of the symbols in the 8-bit ASCII char set.  For example, you could use a left arrow for assignment instead of the = operator.  Then there would be no need for the silly ==.  There are myriads of ways to improve readability and mathematical correctness of the code in the many characters that are unused in the current character set.  I believe that D should move in this direction, especially after glancing at the new 3-character operators that D provides.

However, one obstacle to this is the keyboard.  Either you need new a new keyboard for all these new symbols, or you define some terse way of getting to them like Ctrl, Alt, or function keys, or you have a visual symbol table and select the symbol with your mouse, which would be unacceptably slow.

Suggestions anyone?

-Craig

U¿ytkownik "Craig Black" <cblack@ara.com> napisa³ w wiadomo¶ci news:cv0dso$141l$1@digitaldaemon.com...
> However, one obstacle to this is the keyboard.  Either you need new a new keyboard for all these new symbols, or you define some terse way of
getting
> to them like Ctrl, Alt, or function keys,

I use keyboard shortcuts for Polish diactrics and for many constructs when
writing in TeX. I might use for example ctrl+= for arrow-like assignment as
well. I don't understand where the problem is.
Replacements and addition of some operators need no change in the general
stucture of grammar. Maybe even one can within few days make modified
version of D compiler and so prove that the new pretty syntax is within easy
reach.
--
Dawid Toton

One special symbol is not that bad e.g. Ctrl-=, however lets say we up the number of special symbols to say 5 or 10, then things start getting tricky. Memorizing all those Crtl-this or Alt-that keystrokes could become a chore.

I'm not dising the idea.  I think it would be quite elegant to have more symbols, but I still think the standard keyboard is a problem.  The learning curve is enough for most just with a new language, but add a set of symbols that are not included with the standard keyboard, and it may be too much for them.

-Craig

Dawid Toton schrieb:
> One of basic aims is to achieve good comprehensibility code. It should look
> as clear as possible. So why not use characters from 2200-22FF (unicode) as
> operators? Good programming language should offer free use of such symbols.
> For example: any collection should provide 220A operator as it means simply
> "belogns to".
>  I see no reason for omtting such an obvious improvement!

The idea has been brought up over and over again. I myself like it very much, but: it still would be a huge obstacle for anyone starting to use D.

I, for example, have no experience whatsoever using unicode. I have plenty of experience with Linux and could certainly set up an environment (editor, keyboard, fonts, etc.) to handle unicode, but so far I have never needed to do so. I it were needed to read and write D, it would be a huge hurdle. Most other users are even less experienced and might not know where to find the necessary documentation. Therefore: be prepared to write an introductory chapter about setting up unicode for Windows, Linux and MacOSX in combination with each of the myriads of editors out there. (I don't think people will be willing to switch from their favorite editor just to try out D)

The fundamental problem is probably the size of unicode: There will never be a unified way for keymappings for all unicode characters. Maybe, one day, people will be accustomed to create their own keymap. Up to that time, we will have to stick to the common denominator: ASCII.

One thing that might be possible is a direct mapping between multi-character ASCII operators and single-character unicode characters. That way, people could slowly get started using unicode, but the source can still be directly translated to a pure and readable ASCII representation. Maybe, in a few years, unicode is common enough and D has gained enough momentum to move on.

Yep, once upon a time in galaxy...
it was a language named APL.
It was so well defined and
advanced that community
decided to allocate range
of UNICODE literals
for it. After that it
got even its own
keyboard. And
after that it just
disappeared.
Amen.

"Sic transit gloria mundi"

APL: http://www.answers.com/topic/apl-programming-language?hl=apl

Dawid Toton wrote:
> U¿ytkownik "Craig Black" <cblack@ara.com> napisa³ w wiadomo¶ci
> news:cv0dso$141l$1@digitaldaemon.com...
> 
>>However, one obstacle to this is the keyboard.  Either you need new a new
>>keyboard for all these new symbols, or you define some terse way of
> 
> getting
> 
>>to them like Ctrl, Alt, or function keys,
> 
> 
> I use keyboard shortcuts for Polish diactrics and for many constructs when
> writing in TeX. I might use for example ctrl+= for arrow-like assignment as
> well. I don't understand where the problem is.
> Replacements and addition of some operators need no change in the general
> stucture of grammar. Maybe even one can within few days make modified
> version of D compiler and so prove that the new pretty syntax is within easy
> reach.

I've made stabs at APL on two occasions, two decades apart.

I also do programming in areas of different human languages, and
therefore I daily use at least the Finnish and the U.S. keyboard.

If I were to use a language that needs special characters to
be typed, I would end up having to find them possibly in
different places in the different countries. Also, and what is
worse, I might not be able to type some at all.

There are always ways around this, but the real issue is that
programming is a thing where you really need to not think about
the keyboard or such. (Why do you think almost every programmer
at some time in their life starts to write a text editor of
their own? It's because the keyboard assignments and your
fingers are the medium through which your thoughts go through.

The smallest little imperfection in this makes a big difference.

Writing APL was frustrating, at best. (Of course, reading APL
was about as easy as reading old Perl, and that was bad too.)

We have just a few tens of letters (in the western countries).
The Chinese have tens of thousands. I bet we didn't have
computers yet if we used such a vast set of "characters".

Besides, it is easier to write "<>=" than to have to lear how
exactly a funny looking character has to be keyed in.

For the casual reader it is also easier to read something with
familiar symbols (even if some of them are "words" like "<>=")
than to find starts and arrows and funnies you can't even
figure out a name for in your mind.

-----

All this would slow down the adoption of such a language.
APL is perfect for a lot of things, but it's a dying niche
language.

I wrote:
> 
> Dawid Toton wrote:
> 
>> U¿ytkownik "Craig Black" <cblack@ara.com> napisa³ w wiadomo¶ci
>> news:cv0dso$141l$1@digitaldaemon.com...

Another reason to stick to normal characters is computers
and today's software. Above, on the line where it says "Craig"
I see an upside down question mark, later a word raised to the
third power, and a paragraph mark.

Imagine what I'd see here if this text contained funny program
characters, wrongly displayed!

I bet it takes another 10-15 years before we can discuss this
issue again.

>>> However, one obstacle to this is the keyboard.  Either you need new a new
>>> keyboard for all these new symbols, or you define some terse way of
>>
>>
>> getting
>>
>>> to them like Ctrl, Alt, or function keys,
>>
>>
>>
>> I use keyboard shortcuts for Polish diactrics and for many constructs when
>> writing in TeX. I might use for example ctrl+= for arrow-like assignment as
>> well. I don't understand where the problem is.
>> Replacements and addition of some operators need no change in the general
>> stucture of grammar. Maybe even one can within few days make modified
>> version of D compiler and so prove that the new pretty syntax is within easy
>> reach.
> 
> 
> I've made stabs at APL on two occasions, two decades apart.
> 
> I also do programming in areas of different human languages, and
> therefore I daily use at least the Finnish and the U.S. keyboard.
> 
> If I were to use a language that needs special characters to
> be typed, I would end up having to find them possibly in
> different places in the different countries. Also, and what is
> worse, I might not be able to type some at all.
> 
> There are always ways around this, but the real issue is that
> programming is a thing where you really need to not think about
> the keyboard or such. (Why do you think almost every programmer
> at some time in their life starts to write a text editor of
> their own? It's because the keyboard assignments and your
> fingers are the medium through which your thoughts go through.
> 
> The smallest little imperfection in this makes a big difference.
> 
> Writing APL was frustrating, at best. (Of course, reading APL
> was about as easy as reading old Perl, and that was bad too.)
> 
> We have just a few tens of letters (in the western countries).
> The Chinese have tens of thousands. I bet we didn't have
> computers yet if we used such a vast set of "characters".
> 
> Besides, it is easier to write "<>=" than to have to lear how
> exactly a funny looking character has to be keyed in.
> 
> For the casual reader it is also easier to read something with
> familiar symbols (even if some of them are "words" like "<>=")
> than to find starts and arrows and funnies you can't even
> figure out a name for in your mind.
> 
> -----
> 
> All this would slow down the adoption of such a language.
> APL is perfect for a lot of things, but it's a dying niche
> language.

"Norbert Nemec" <Norbert@Nemec-online.de> wrote in message news:cv14te$20h2$1@digitaldaemon.com...
> I, for example, have no experience whatsoever using unicode. I have plenty of experience with Linux and could certainly set up an environment (editor, keyboard, fonts, etc.) to handle unicode, but so far I have never needed to do so. I it were needed to read and write D, it would be a huge hurdle. Most other users are even less experienced and might not know where to find the necessary documentation. Therefore: be prepared to write an introductory chapter about setting up unicode for Windows, Linux and MacOSX in combination with each of the myriads of editors out there. (I don't think people will be willing to switch from their favorite editor just to try out D)

I agree. Unicode is the future, and the D language needs to support it, but it needs to be ubiquitous for the D syntax to require it. We aren't there yet.

Craig Black wrote:

> However, one obstacle to this is the keyboard.  Either you need new a new keyboard for all these new symbols, or you define some terse way of getting to them like Ctrl, Alt, or function keys, or you have a visual symbol table and select the symbol with your mouse, which would be unacceptably slow.

There are such visual tables in most modern operating systems,
for instance: http://www.algonet.se/~afb/d/unicode-palette.png
(and you can use the alt-keypad workaround in other systems)

But this does not mean that they are faster to use than writing
plain old US-ASCII, however... (such as '===' instead of '≡')
But *allowing* them is a lot different from requiring them ?


For instance, D already allows a truckload of weird characters:
http://www.algonet.se/~afb/d/universalalphas/universalalphas.html
(100 KB! of UTF-8). Not that that every linker likes it, but...

Mixing such identifier names with a bunch of new symbol operators
is bound to make reading the code very "exciting", in a kind of
Egyptologian sense... But it could still be allowed in the language ?


So if you want a lot of other programmers to be able to read your code,
I'd stick to using ASCII and English. Perhaps with a few exceptions,
like some peoples full names ;) and eg. localized docs and messages ?

There should always be a US-ASCII alternative, and UTF-8 provides one...
But I think that the unicode symbols suggested could be a nice addition:
http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList/UnicodeOperators


Not sure how hard it would be to add to the lexer. Probably not very ?

--anders


PS. Why stop at just characters ? With the HTML source format that
    D allows, you can "spice up" your code using images and Flash!
    :-D