• Dawid Toton (14/14) Feb 16 2005 One of basic aims is to achieve good comprehensibility code. It should l...
• Craig Black (17/36) Feb 16 2005 I like the unicode idea, but I think that would be difficult to pull off...
• Dawid Toton (12/15) Feb 16 2005 getting
• Craig Black (9/9) Feb 16 2005 One special symbol is not that bad e.g. Ctrl-=, however lets say we up t...
• Georg Wrede (30/48) Feb 17 2005 I've made stabs at APL on two occasions, two decades apart.
• Georg Wrede (9/76) Feb 17 2005 Another reason to stick to normal characters is computers
• =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= (24/28) Feb 20 2005 There are such visual tables in most modern operating systems,
• Norbert Nemec (23/29) Feb 16 2005 The idea has been brought up over and over again. I myself like it very
• Walter (5/15) Feb 17 2005 I agree. Unicode is the future, and the D language needs to support it, ...
• Andrew Fedoniouk (14/14) Feb 16 2005 Yep, once upon a time in galaxy...

"Dawid Toton" <dad o2.pl> writes:

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

"Craig Black" <cblack ara.com> writes:

"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 

"Dawid Toton" <dad o2.pl> writes:

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

"Craig Black" <cblack ara.com> writes:

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 

Georg Wrede <georg.wrede nospam.org> writes:

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.

Georg Wrede <georg.wrede nospam.org> writes:

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.

=?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:

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

Norbert Nemec <Norbert Nemec-online.de> writes:

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.

"Walter" <newshound digitalmars.com> writes:

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

"Andrew Fedoniouk" <news terrainformatica.com> writes:

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