Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #149611 > unrolled thread

Unicode in C Sources

Back to article view | Back to comp.lang.c

Contents

  Unicode in C Sources F Russell <fr@random.info> - 2020-02-01 17:12 +0000
    Re: Unicode in C Sources Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-01 17:37 +0000
      Re: Unicode in C Sources Anton Shepelev <anton.txt@gmail.com> - 2020-02-01 20:43 +0300
        Re: Unicode in C Sources Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-02-01 10:57 -0800
          Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-02 16:58 +0100
            Re: Unicode in C Sources F Russell <fr@random.info> - 2020-02-02 17:05 +0000
              Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-02 19:52 +0100
                Re: Unicode in C Sources Bart <bc@freeuk.com> - 2020-02-02 19:20 +0000
              Re: Unicode in C Sources Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-03 12:38 +0000
                Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-03 09:16 -0500
                  Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-03 15:32 +0100
                    Re: Unicode in C Sources Öö Tiib <ootiib@hot.ee> - 2020-02-03 09:01 -0800
                    Re: Unicode in C Sources Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-03 21:15 +0000
                Re: Unicode in C Sources F Russell <fr@random.info> - 2020-02-04 02:06 +0000
                Re: Unicode in C Sources F Russell <fr@random.info> - 2020-02-04 02:19 +0000
                  Re: Unicode in C Sources Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-04 02:50 +0000
                  Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-04 08:16 +0100
      Re: Unicode in C Sources Bart <bc@freeuk.com> - 2020-02-01 18:10 +0000
        Re: Unicode in C Sources Richard Damon <Richard@Damon-Family.org> - 2020-02-01 15:19 -0500
          Re: Unicode in C Sources Manfred <invalid@add.invalid> - 2020-02-02 00:13 +0100
            Re: Unicode in C Sources Manfred <invalid@add.invalid> - 2020-02-02 00:46 +0100
              Re: Unicode in C Sources Bart <bc@freeuk.com> - 2020-02-02 00:24 +0000
            Re: Unicode in C Sources Richard Damon <Richard@Damon-Family.org> - 2020-02-02 08:14 -0500
              Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-02 17:59 +0100
                Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-02 14:44 -0500
                  Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-02 21:49 +0100
                    Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-02 16:58 -0500
                      Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-03 15:33 +0100
                        Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-03 15:38 +0100
                        Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-03 10:25 -0500
                          Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-03 19:11 +0100
                            Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-03 15:59 -0500
                              Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-04 16:51 +0100
                                Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-04 16:05 -0500
                                Re: Unicode in C Sources Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-19 12:17 -0800
        Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-02 17:09 +0100
          Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-02 14:46 -0500
            Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-02 21:39 +0100
              Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-02 17:07 -0500
                Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-03 13:12 +0100
                  Re: Unicode in C Sources jacobnavia <jacob@jacob.remcomp.fr> - 2020-02-03 16:46 +0100
                  Re: Unicode in C Sources Bart <bc@freeuk.com> - 2020-02-03 16:47 +0000
                    Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-03 13:36 -0800
                      Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-03 23:56 +0100
                  Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-03 13:06 -0500
                    Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-03 22:25 +0100
                      Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-03 13:29 -0800
                        Re: Unicode in C Sources Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-19 12:30 -0800
                          Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-19 14:19 -0800
                            Re: Unicode in C Sources Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 07:50 -0700
                              Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-02 08:16 -0700
                      Re: Unicode in C Sources Bart <bc@freeuk.com> - 2020-02-03 22:33 +0000
                      Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-03 23:05 -0500
                      Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-03 23:10 -0500
                    Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-04 18:05 +0100
                      Re: Unicode in C Sources already5chosen@yahoo.com - 2020-02-04 09:38 -0800
                        Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-04 18:46 +0100
                      Re: Unicode in C Sources James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-04 16:07 -0500
              Re: Unicode in C Sources Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-02-02 14:54 -0800
        Re: Unicode in C Sources Siri Cruise <chine.bleu@yahoo.com> - 2020-02-03 15:10 -0800
    Re: Unicode in C Sources jacobnavia <jacob@jacob.remcomp.fr> - 2020-02-03 07:47 +0100
      Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-03 14:00 +0100
        Re: Unicode in C Sources jacobnavia <jacob@jacob.remcomp.fr> - 2020-02-03 16:45 +0100
          Re: Unicode in C Sources Guillaume <message@bottle.org> - 2020-02-03 17:54 +0100
          Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-03 22:36 +0100
            Re: Unicode in C Sources jacobnavia <jacob@jacob.remcomp.fr> - 2020-02-04 16:33 +0100
              Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-04 16:45 +0100
                Re: Unicode in C Sources Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-02-04 13:02 -0800
                  Re: Unicode in C Sources jacobnavia <jacob@jacob.remcomp.fr> - 2020-02-04 23:18 +0100
                    Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-05 11:07 +0100
                      Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-05 14:49 +0100
                        Re: Unicode in C Sources Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-16 06:23 -0800
                  Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-05 10:54 +0100
                Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-05 14:51 +0100
                  Re: Unicode in C Sources Bart <bc@freeuk.com> - 2020-02-05 14:03 +0000
                    Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-05 16:31 +0100
                      Re: Unicode in C Sources Bart <bc@freeuk.com> - 2020-02-05 15:59 +0000
                        Re: Unicode in C Sources scott@slp53.sl.home (Scott Lurndal) - 2020-02-05 16:02 +0000
                          Re: Unicode in C Sources Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-05 16:59 +0000
                            Re: Unicode in C Sources Bart <bc@freeuk.com> - 2020-02-05 18:02 +0000
                              Re: Unicode in C Sources jacobnavia <jacob@jacob.remcomp.fr> - 2020-02-05 19:37 +0100
                              Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-05 19:37 +0100
                                Re: Unicode in C Sources jacobnavia <jacob@jacob.remcomp.fr> - 2020-02-05 21:02 +0100
                                  Re: Unicode in C Sources Ian Collins <ian-news@hotmail.com> - 2020-02-06 10:34 +1300
                                  Re: Unicode in C Sources Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-05 23:10 +0000
                                    Re: Unicode in C Sources Manfred <noname@add.invalid> - 2020-02-06 13:53 +0100
                                      Re: Unicode in C Sources Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-06 13:26 +0000
                                  Re: Unicode in C Sources Richard Damon <Richard@Damon-Family.org> - 2020-02-06 07:27 -0500
                                Re: Unicode in C Sources Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-05 23:03 +0000
                                  Re: Unicode in C Sources Mikko Rauhala <mjr@iki.fi> - 2020-02-06 10:46 +0000
                              Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-05 21:47 +0100
                              Re: Unicode in C Sources Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-05 22:50 +0000
                            Re: Unicode in C Sources scott@slp53.sl.home (Scott Lurndal) - 2020-02-07 00:25 +0000
                              Re: Unicode in C Sources Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-07 02:07 +0000
                  Re: Unicode in C Sources David Brown <david.brown@hesbynett.no> - 2020-02-05 16:26 +0100
        Re: Unicode in C Sources antispam@math.uni.wroc.pl - 2020-04-18 03:58 +0000

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#149663

Le 01/02/2020 à 18:12, F Russell a écrit :
> Should it be possible to write C source files in Unicode?
> 
> Now, only former-ASCII characters are allowed but it would
> be nice to be able to write:
> 
> cos(φ) * ω2 - sin(θ) * ω3
> 
> rather than:
> 
> cos(phi) * omega2 - sin(theta) * omega3
> 
> It would seem that this should be a top priority with
> the standards committee.
> 

I disagree. As others have said, how do you type those greek letters?

And besides that, it is possible now for an indian programmer to read 
and understand code written in France, and viceversa. If the indian 
programmers start using sanskrit characters, japanese and chinese use 
their ideograms, we start having the problem of the guys building the 
Babel tower...

Nobody understands anything any more.

Let's keep an internationally recognized SUBSET of all possible 
characters in all possible languages that is common to all of us.

For historical reasons, ASCII does the job. And you can write ANYTHING 
in ASCII, from C to C# from SQL to Python, from Ruby to Cobol.

Let's keep that.

[toc] | [prev] | [next] | [standalone]

#149668

On 03/02/2020 07:47, jacobnavia wrote:
> Le 01/02/2020 à 18:12, F Russell a écrit :
>> Should it be possible to write C source files in Unicode?
>>
>> Now, only former-ASCII characters are allowed but it would
>> be nice to be able to write:
>>
>> cos(φ) * ω2 - sin(θ) * ω3
>>
>> rather than:
>>
>> cos(phi) * omega2 - sin(theta) * omega3
>>
>> It would seem that this should be a top priority with
>> the standards committee.
>>
> 
> I disagree. As others have said, how do you type those greek letters?
> 
> And besides that, it is possible now for an indian programmer to read
> and understand code written in France, and viceversa. If the indian
> programmers start using sanskrit characters, japanese and chinese use
> their ideograms, we start having the problem of the guys building the
> Babel tower...
> 
> Nobody understands anything any more.
> 
> Let's keep an internationally recognized SUBSET of all possible
> characters in all possible languages that is common to all of us.
> 
> For historical reasons, ASCII does the job. And you can write ANYTHING
> in ASCII, from C to C# from SQL to Python, from Ruby to Cobol.
> 
> Let's keep that.

At the risk of straying from C, it's worth noting that Python is quite
happy with Unicode identifiers such as "π = 3.14", and I believe that is
common amongst other more modern languages.  Does the ability to write
non-ASCII identifiers lead to problems with these languages?  Or are we
(including me here) worrying about nothing?

[toc] | [prev] | [next] | [standalone]

#149678

Le 03/02/2020 à 14:00, David Brown a écrit :

> At the risk of straying from C, it's worth noting that Python is quite
> happy with Unicode identifiers such as "π = 3.14", and I believe that is
> common amongst other more modern languages.  Does the ability to write
> non-ASCII identifiers lead to problems with these languages?  Or are we
> (including me here) worrying about nothing?
> 

You do not even mention my argument: An indian programmer is maybe not 
used to see greek letters and maybe he/she doesn't know them at all!

Do YOU know sanskrit? Or Indian letters? or Chinese letters?

C and Python do support any kind of Unicode in character strings and 
THAT IS ENOUGH!

My argument was that if you understand greek letters, other cultures 
maybe do NOT. All programmers in all the world can read ASCII though.

[toc] | [prev] | [next] | [standalone]

#149684

Le 03/02/2020 à 16:45, jacobnavia a écrit :
> Le 03/02/2020 à 14:00, David Brown a écrit :
> 
>> At the risk of straying from C, it's worth noting that Python is quite
>> happy with Unicode identifiers such as "π = 3.14", and I believe that is
>> common amongst other more modern languages.  Does the ability to write
>> non-ASCII identifiers lead to problems with these languages?  Or are we
>> (including me here) worrying about nothing?
>>
> 
> You do not even mention my argument: An indian programmer is maybe not 
> used to see greek letters and maybe he/she doesn't know them at all!
> 
> Do YOU know sanskrit? Or Indian letters? or Chinese letters?
> 
> C and Python do support any kind of Unicode in character strings and 
> THAT IS ENOUGH!
> 
> My argument was that if you understand greek letters, other cultures 
> maybe do NOT. All programmers in all the world can read ASCII though.

Whereas there's a good chance that greek letters would be understood by 
most, as they are commonly used in math worldwide - so anyone with at 
least some math background should be relatively OK with them - this is 
not the case with other alphabets. Of course, greek letters are an 
exception here, and many other alphabets are a lot less pervasive and 
would be a disaster for sharing code.

Heck, even greek letters would be problematic beyond single-letter 
identifiers. Whereas (again due to our math background) most of us would 
have no big problem with "pi", "sigma", ... letters, identifiers made of 
several greek letters would already be pretty hard to make sense of. 
Would a variable called "pi sigma delta nu" ring any bell for anyone 
except greek people? Would we even remember them? I don't think so. 
We're just not used to that. In that respect, the above example of "pi = 
3.14" is a bad example, because it makes it look obvious, whereas it is 
absolutely not in the general case.

So yeah, for anyone willing to share code, it's just a no-no in my book 
as well. I admit that it's not quite fair to all people whose native 
alphabet is not latin, but it's not fair either that we pretty much all 
have to use English to communicate worldwide - which is exactly what we 
are all doing here, from many different parts of the world - it's just 
that it has become the de facto universal language, just like the latin 
alphabet has become the de factor universal alphabet, and even more so 
in programming languages. We can find this very unfair, but there's like 
zero chance we can change that at this point, so we better just chuck it 
up and move on. Just my opinion.

[toc] | [prev] | [next] | [standalone]

#149697

On 03/02/2020 16:45, jacobnavia wrote:
> Le 03/02/2020 à 14:00, David Brown a écrit :
> 
>> At the risk of straying from C, it's worth noting that Python is quite
>> happy with Unicode identifiers such as "π = 3.14", and I believe that is
>> common amongst other more modern languages.  Does the ability to write
>> non-ASCII identifiers lead to problems with these languages?  Or are we
>> (including me here) worrying about nothing?
>>
> 
> You do not even mention my argument: An indian programmer is maybe not 
> used to see greek letters and maybe he/she doesn't know them at all!

I didn't need to mention your argument there - it was basically the same 
as I had already written in this thread.

> 
> Do YOU know sanskrit? Or Indian letters? or Chinese letters?
> 
> C and Python do support any kind of Unicode in character strings and 
> THAT IS ENOUGH!
> 

Python (and many other languages) also support Unicode in identifiers. 
My question is, does anyone know if this /actually/ causes problems in 
practice?  I am not asking if you think it is a good idea or not, or 
what potential problems there could be (since those have been covered 
already).

> My argument was that if you understand greek letters, other cultures 
> maybe do NOT. All programmers in all the world can read ASCII though.

There are a few programming languages that are not ASCII based at all. 
Not many, but some.

The suggestion was for use of Greek letters for mathematical symbols, 
and I think that a familiarity with a few Greek letters (such as π) will 
be common amongst programmers even if their native language is not Latin 
based, though they may be considered as "mathematical symbols" rather 
than "Greek letters".

[toc] | [prev] | [next] | [standalone]

#149726

Le 03/02/2020 à 22:36, David Brown a écrit :
> My question is, does anyone know if this /actually/ causes problems in 
> practice?


Suppose you write pi as a greek letter identifier.

1) You edit the program source text. You can't use the search or the 
search+replace features of your editor, there is no way to type pi as a 
greek letter in your keyboard.

2) I use a small font in the mail reader I am using. I misread pi as "n" 
the first time I saw it. From the context I saw that I had to look 
closer and then I saw the greek letter.

3) The compiler must be prepared to output those characters in 
warnings/errors

"Undefined identifier \u..." is not really helpful.

4) How about the linker? Do all linker support Unicode?

5) You will have the same problem as in the editor if you want to 
display the value of pi in the debugger. No way to type it.

ETC!

Those problems appear after several minutes of reflection. Imagine how 
many are lurking behind those!

[toc] | [prev] | [next] | [standalone]

#149727

On 04/02/2020 16:33, jacobnavia wrote:
> Le 03/02/2020 à 22:36, David Brown a écrit :
>> My question is, does anyone know if this /actually/ causes problems in
>> practice?
> 
> 
> Suppose you write pi as a greek letter identifier.
> 
> 1) You edit the program source text. You can't use the search or the
> search+replace features of your editor, there is no way to type pi as a
> greek letter in your keyboard.
> 
> 2) I use a small font in the mail reader I am using. I misread pi as "n"
> the first time I saw it. From the context I saw that I had to look
> closer and then I saw the greek letter.
> 
> 3) The compiler must be prepared to output those characters in
> warnings/errors
> 
> "Undefined identifier \u..." is not really helpful.
> 
> 4) How about the linker? Do all linker support Unicode?
> 
> 5) You will have the same problem as in the editor if you want to
> display the value of pi in the debugger. No way to type it.
> 
> ETC!
> 
> Those problems appear after several minutes of reflection. Imagine how
> many are lurking behind those!

Look, I /know/ about all these potential problems.  I wrote about
several of them.  Most of these have already been mentioned.

My question was, has anyone /seen/ any of these problems actually
occurring in practice with programming languages that support Unicode
identifiers.

The answer so far is "no" - no one here has come across problems as a
result of programming languages supporting Unicode identifiers.  Of
course, that could be because no one has bothered answering, or because
people in this group mainly use C (though I know that many also use
other languages).  I know /I/ have never had issues with Unicode
identifiers in Python - I haven't even heard of any, though they have
exactly the same potential problems as Unicode identifiers in C.

[toc] | [prev] | [next] | [standalone]

#149738

David Brown <david.brown@hesbynett.no> writes:
> On 04/02/2020 16:33, jacobnavia wrote:
[...]
>> Those problems appear after several minutes of reflection. Imagine how
>> many are lurking behind those!
>
> Look, I /know/ about all these potential problems.  I wrote about
> several of them.  Most of these have already been mentioned.
>
> My question was, has anyone /seen/ any of these problems actually
> occurring in practice with programming languages that support Unicode
> identifiers.
>
> The answer so far is "no" - no one here has come across problems as a
> result of programming languages supporting Unicode identifiers.  Of
> course, that could be because no one has bothered answering, or because
> people in this group mainly use C (though I know that many also use
> other languages).  I know /I/ have never had issues with Unicode
> identifiers in Python - I haven't even heard of any, though they have
> exactly the same potential problems as Unicode identifiers in C.

I also haven't come across problems caused by non-ASCII characters
in code.  But that's largely because (nearly) none of the code I've
dealt with has used non-ASCII characters.

The question is, do non-ASCII characters (other than, for example,
accented letters supported on regional keyboards) cause problems
in practice *when they're used*?

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#149743

Le 04/02/2020 à 22:02, Keith Thompson a écrit :
> I also haven't come across problems caused by non-ASCII characters
> in code.  But that's largely because (nearly) none of the code I've
> dealt with has used non-ASCII characters.
> 

You are programming since several decades, and you have surely read a 
lot of code. None of it used unicode characters, and that is not because 
editors do not support unicode. Even my old faithful vim supports them 
without any problem.

Have you asked yourself why this is so?

> The question is, do non-ASCII characters (other than, for example,
> accented letters supported on regional keyboards) cause problems
> in practice*when they're used*?

In practice I try to avoid accented letters as much as I can in coding 
since I have a long experience of bugs and problems each time I used 
them outside word/document processing of course.

Even if they are supported in french keyboards, I know if my code will 
be read or used outside France people will find that they can't type 
them, etc, the problems I mentioned above. And that is only accented 
letters, that are part of national language standards.

To give a bit of actual data into these discussions let's look at greek 
software. Do greek programmers use greek in their programs?

An example is Kalithea, a python front end for mercurial or git. From 
the git deltas available in their repository (https://kallithea-scm.org) 
there isn't a single greek letter in sight.

In other greek software, for example

https://github.com/eellak/gsoc2019-greek-morpho

a Greek open source "Morphological dictionary and application of it to 
Greek spelling tools", greek letters and greek is used extensively in 
their python sources, surely because of the subject matter of the 
software: they are building software for the greek language!


We see here in this tiny sample that when you are building software to 
be used all over the world by many people you stick to english. If you 
are building language specific tools that will be used ONLY in a single 
country you use the specific language in your code.

entier main(vide)
{
	imprimerf("Bonjour!");
}

:-)

[toc] | [prev] | [next] | [standalone]

#149754

On 04/02/2020 23:18, jacobnavia wrote:
> Le 04/02/2020 à 22:02, Keith Thompson a écrit :
>> I also haven't come across problems caused by non-ASCII characters
>> in code.  But that's largely because (nearly) none of the code I've
>> dealt with has used non-ASCII characters.
>>
> 
> You are programming since several decades, and you have surely read a
> lot of code. None of it used unicode characters, and that is not because
> editors do not support unicode. Even my old faithful vim supports them
> without any problem.
> 
> Have you asked yourself why this is so?

Presumably the prime reason he has seen little use of Unicode in C
programming is that few C compilers or other C-related tools (other than
editors) have good support for Unicode.

And presumably the prime reason he has seen little use of non-ASCII
elsewhere is that he is an American living in America (as far as I
know), where English is dominant in general and overwhelmingly dominant
in the software world.  ASCII was made by American programmers for
American programmers - this means the need for non-ASCII characters in
identifiers will be small.

A more useful question would be why /you/ haven't seen more non-ASCII
characters in identifiers.  You are from a country which takes pride in
using its own language where possible, and spelling it accurately (here
in Norway we are more inclined to use English for technical matters, or
at least to anglicise spelling).

> 
>> The question is, do non-ASCII characters (other than, for example,
>> accented letters supported on regional keyboards) cause problems
>> in practice*when they're used*?
> 
> In practice I try to avoid accented letters as much as I can in coding
> since I have a long experience of bugs and problems each time I used
> them outside word/document processing of course.
> 
> Even if they are supported in french keyboards, I know if my code will
> be read or used outside France people will find that they can't type
> them, etc, the problems I mentioned above. And that is only accented
> letters, that are part of national language standards.
> 

This sounds very much like you are saying support for Unicode in
programming is not a problem in practice, because you avoid using it in
cases where it might be a problem.

> To give a bit of actual data into these discussions let's look at greek
> software. Do greek programmers use greek in their programs?
> 
> An example is Kalithea, a python front end for mercurial or git. From
> the git deltas available in their repository (https://kallithea-scm.org)
> there isn't a single greek letter in sight.
> 
> In other greek software, for example
> 
> https://github.com/eellak/gsoc2019-greek-morpho
> 
> a Greek open source "Morphological dictionary and application of it to
> Greek spelling tools", greek letters and greek is used extensively in
> their python sources, surely because of the subject matter of the
> software: they are building software for the greek language!
> 

And there is a key difference.  The first example is for wide-spread use
- and that means English (both as a language and an alphabet).  The
second is language-specific, and uses Unicode identifiers.

Python supports Unicode identifiers.  It does not seem to cause a
problem in either of these projects.

> 
> We see here in this tiny sample that when you are building software to
> be used all over the world by many people you stick to english. If you
> are building language specific tools that will be used ONLY in a single
> country you use the specific language in your code.
> 
> entier main(vide)
> {
>     imprimerf("Bonjour!");
> }
> 
> :-)

[toc] | [prev] | [next] | [standalone]

#149755

On 2/5/2020 11:07 AM, David Brown wrote:
> On 04/02/2020 23:18, jacobnavia wrote:
>> Le 04/02/2020 à 22:02, Keith Thompson a écrit :
>>> I also haven't come across problems caused by non-ASCII characters
>>> in code.  But that's largely because (nearly) none of the code I've
>>> dealt with has used non-ASCII characters.
>>>
>>
>> You are programming since several decades, and you have surely read a
>> lot of code. None of it used unicode characters, and that is not because
>> editors do not support unicode. Even my old faithful vim supports them
>> without any problem.
>>
>> Have you asked yourself why this is so?
> 
> A more useful question would be why /you/ haven't seen more non-ASCII
> characters in identifiers.  You are from a country which takes pride in
> using its own language where possible, and spelling it accurately (here
> in Norway we are more inclined to use English for technical matters, or
> at least to anglicise spelling).
> 
I had the same question. I seem to remember having encountered long ago 
some code written by French people, wherein some identifiers used French 
names (sort of - no accents so still ASCII). IIRC, that was a little bit 
inconvenient (my fault, I am ignorant in that language).
However, net of the trouble with similar glyphs that you pointed out, I 
find the possibility of some symbol (greek) letters in math code 
somewhat attractive.

[toc] | [prev] | [next] | [standalone]

#150050

Manfred <noname@add.invalid> writes:

> [Assuming glyph confusion is avoided,] I find the possibility of
> some symbol (greek) letters in math code somewhat attractive.

Is it important to have even more one-character identifiers?
Rather than use greek characters just spell them out in regular
letters:  alpha, beta, gamma, delta, epsilon, zeta, eta, theta,
iota, kappa, lambda, mu, nu, xi, omikron, pi, rho, sigma, tau,
upsilon, phi, chi, psi, or omega.

[toc] | [prev] | [next] | [standalone]

#149752

On 04/02/2020 22:02, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 04/02/2020 16:33, jacobnavia wrote:
> [...]
>>> Those problems appear after several minutes of reflection. Imagine how
>>> many are lurking behind those!
>>
>> Look, I /know/ about all these potential problems.  I wrote about
>> several of them.  Most of these have already been mentioned.
>>
>> My question was, has anyone /seen/ any of these problems actually
>> occurring in practice with programming languages that support Unicode
>> identifiers.
>>
>> The answer so far is "no" - no one here has come across problems as a
>> result of programming languages supporting Unicode identifiers.  Of
>> course, that could be because no one has bothered answering, or because
>> people in this group mainly use C (though I know that many also use
>> other languages).  I know /I/ have never had issues with Unicode
>> identifiers in Python - I haven't even heard of any, though they have
>> exactly the same potential problems as Unicode identifiers in C.
> 
> I also haven't come across problems caused by non-ASCII characters
> in code.  But that's largely because (nearly) none of the code I've
> dealt with has used non-ASCII characters.
> 
> The question is, do non-ASCII characters (other than, for example,
> accented letters supported on regional keyboards) cause problems
> in practice *when they're used*?
> 

I'd say that was an additional question (and a good one), rather than a
replacement for my question.  Perhaps there are several questions that
need asking:

Has anyone experience with identifiers using non-ASCII identifiers with
accents or additional Latin alphabet letters?

Has that caused any complications?

Has anyone experience with identifiers of significantly different
alphabets or symbols?

Has that caused any complications?

[toc] | [prev] | [next] | [standalone]

#149756

On 2/4/2020 4:45 PM, David Brown wrote:
> Look, I/know/  about all these potential problems.  I wrote about
> several of them.  Most of these have already been mentioned.
> 
> My question was, has anyone/seen/  any of these problems actually
> occurring in practice with programming languages that support Unicode
> identifiers.
> 
> The answer so far is "no" - no one here has come across problems as a
> result of programming languages supporting Unicode identifiers.  Of
> course, that could be because no one has bothered answering, or because
> people in this group mainly use C (though I know that many also use
> other languages).  I know/I/  have never had issues with Unicode
> identifiers in Python - I haven't even heard of any, though they have
> exactly the same potential problems as Unicode identifiers in C.

Reverting the question, also in terms of actual experience: in what 
circumstances have you found Unicode identifiers substantially more 
useful in practice than ASCII in Python code?

[toc] | [prev] | [next] | [standalone]

#149757

On 05/02/2020 13:51, Manfred wrote:
> On 2/4/2020 4:45 PM, David Brown wrote:
>> Look, I/know/  about all these potential problems.  I wrote about
>> several of them.  Most of these have already been mentioned.
>>
>> My question was, has anyone/seen/  any of these problems actually
>> occurring in practice with programming languages that support Unicode
>> identifiers.
>>
>> The answer so far is "no" - no one here has come across problems as a
>> result of programming languages supporting Unicode identifiers.  Of
>> course, that could be because no one has bothered answering, or because
>> people in this group mainly use C (though I know that many also use
>> other languages).  I know/I/  have never had issues with Unicode
>> identifiers in Python - I haven't even heard of any, though they have
>> exactly the same potential problems as Unicode identifiers in C.
> 
> Reverting the question, also in terms of actual experience: in what 
> circumstances have you found Unicode identifiers substantially more 
> useful in practice than ASCII in Python code?

I find the ASCII "$" extremely useful in C, especially for generated C 
code, but it's not standard C and while gcc allows "$", some compilers 
don't like it.

Notably Tiny C, yet Unicode identifiers are supported. Bizarre.

[toc] | [prev] | [next] | [standalone]

#149760

On 05/02/2020 15:03, Bart wrote:
> On 05/02/2020 13:51, Manfred wrote:
>> On 2/4/2020 4:45 PM, David Brown wrote:
>>> Look, I/know/  about all these potential problems.  I wrote about
>>> several of them.  Most of these have already been mentioned.
>>>
>>> My question was, has anyone/seen/  any of these problems actually
>>> occurring in practice with programming languages that support Unicode
>>> identifiers.
>>>
>>> The answer so far is "no" - no one here has come across problems as a
>>> result of programming languages supporting Unicode identifiers.  Of
>>> course, that could be because no one has bothered answering, or because
>>> people in this group mainly use C (though I know that many also use
>>> other languages).  I know/I/  have never had issues with Unicode
>>> identifiers in Python - I haven't even heard of any, though they have
>>> exactly the same potential problems as Unicode identifiers in C.
>>
>> Reverting the question, also in terms of actual experience: in what
>> circumstances have you found Unicode identifiers substantially more
>> useful in practice than ASCII in Python code?
> 
> I find the ASCII "$" extremely useful in C, especially for generated C
> code, but it's not standard C and while gcc allows "$", some compilers
> don't like it.
> 
> Notably Tiny C, yet Unicode identifiers are supported. Bizarre.
> 

Does Tiny C support Unicode identifiers?

I can well see there being more use for allowing the odd symbols that
are currently disallowed in C identifiers, but which are easy to type on
many keyboards.  That would include @ £ § $ € (some of these are ASCII,
others not).  I'd imagine they could be very useful for generated code -
stick an @ in front of each identifier from the original source and
you'd never have conflicts with keywords in C that happen to coincide
with valid identifiers in the original language, and you could easily
distinguish "source" identifiers from extra ones in the generated C.
For manually written code, you could use them for handling external
names (such as database columns, field names in files, or whatever)
without conflict with keywords.

[toc] | [prev] | [next] | [standalone]

#149761

On 05/02/2020 15:31, David Brown wrote:
> On 05/02/2020 15:03, Bart wrote:

>> I find the ASCII "$" extremely useful in C, especially for generated C
>> code, but it's not standard C and while gcc allows "$", some compilers
>> don't like it.
>>
>> Notably Tiny C, yet Unicode identifiers are supported. Bizarre.
>>
> 
> Does Tiny C support Unicode identifiers?

Well, it compiles this program that Ben posted:

#include <stdio.h>
#include <math.h>

int main()
{
      double φ = 0.5, ω2 = 0.2, θ = -0.5, ω3 = 0.1;
      printf("%g\n", cos(φ) * ω2 - sin(θ) * ω3);
}

(Which uses Greek phi, omega and theta in case they don't come out.)

Although it doesn't like the byte-order-mark at the start of the file, 
which Notepad seems to insert even for UTF8.


> I can well see there being more use for allowing the odd symbols that
> are currently disallowed in C identifiers, but which are easy to type on
> many keyboards.  That would include @ £ § $ € (some of these are ASCII,
> others not).  I'd imagine they could be very useful for generated code -
> stick an @ in front of each identifier from the original source and
> you'd never have conflicts with keywords in C that happen to coincide
> with valid identifiers in the original language, and you could easily
> distinguish "source" identifiers from extra ones in the generated C.
> For manually written code, you could use them for handling external
> names (such as database columns, field names in files, or whatever)
> without conflict with keywords.

Yes, that's what I use in my language, but I chose '`' (back-tick). 
Without that I it would be difficult to call C's exit() function as a 
foreign function, as 'exit' is a keyword.

(@ has another use; a sole $ is a keyword (A[$] is a way to access the 
last element of A); € isn't on my keyboard (I have to type Alt+128), 
while the others aren't ASCII. £ used to be in the ANSI 8-bit character 
set, with a few other useful characters, but now it's Unicode.)

[toc] | [prev] | [next] | [standalone]

#149762

Bart <bc@freeuk.com> writes:
>On 05/02/2020 15:31, David Brown wrote:
>> On 05/02/2020 15:03, Bart wrote:
>
>>> I find the ASCII "$" extremely useful in C, especially for generated C
>>> code, but it's not standard C and while gcc allows "$", some compilers
>>> don't like it.
>>>
>>> Notably Tiny C, yet Unicode identifiers are supported. Bizarre.
>>>
>> 
>> Does Tiny C support Unicode identifiers?
>
>Well, it compiles this program that Ben posted:
>
>#include <stdio.h>
>#include <math.h>
>
>int main()
>{
>      double φ = 0.5, ω2 = 0.2, θ = -0.5, ω3 = 0.1;
>      printf("%g\n", cos(φ) * ω2 - sin(θ) * ω3);
>}
>
>(Which uses Greek phi, omega and theta in case they don't come out.)

And that parenthetical comment is the very best reason _not_ to use
Unicode identifiers in C and C++ programs :-)

[toc] | [prev] | [next] | [standalone]

#149765

scott@slp53.sl.home (Scott Lurndal) writes:

> Bart <bc@freeuk.com> writes:
>>On 05/02/2020 15:31, David Brown wrote:
>>> On 05/02/2020 15:03, Bart wrote:
>>
>>>> I find the ASCII "$" extremely useful in C, especially for generated C
>>>> code, but it's not standard C and while gcc allows "$", some compilers
>>>> don't like it.
>>>>
>>>> Notably Tiny C, yet Unicode identifiers are supported. Bizarre.
>>>>
>>> 
>>> Does Tiny C support Unicode identifiers?
>>
>>Well, it compiles this program that Ben posted:
>>
>>#include <stdio.h>
>>#include <math.h>
>>
>>int main()
>>{
>>      double φ = 0.5, ω2 = 0.2, θ = -0.5, ω3 = 0.1;
>>      printf("%g\n", cos(φ) * ω2 - sin(θ) * ω3);
>>}
>>
>>(Which uses Greek phi, omega and theta in case they don't come out.)
>
> And that parenthetical comment is the very best reason _not_ to use
> Unicode identifiers in C and C++ programs :-)

It's (nearly) the third decade of the 21st century.  I take that remark
as a rebuke to our profession, but also as a prompt to do better.

You should name and shame your posting software (unless you have
deliberately configured it to mess up such a well-known character
encoding).  I hope there is at least an outstanding bug report against
it.  Of course you may have very good reasons to use old and
unmaintained (or even unmaintainable) software, but people should still
know it can't cope with UTF-8.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#149767

On 05/02/2020 16:59, Ben Bacarisse wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
> 
>> Bart <bc@freeuk.com> writes:
>>> On 05/02/2020 15:31, David Brown wrote:
>>>> On 05/02/2020 15:03, Bart wrote:
>>>
>>>>> I find the ASCII "$" extremely useful in C, especially for generated C
>>>>> code, but it's not standard C and while gcc allows "$", some compilers
>>>>> don't like it.
>>>>>
>>>>> Notably Tiny C, yet Unicode identifiers are supported. Bizarre.
>>>>>
>>>>
>>>> Does Tiny C support Unicode identifiers?
>>>
>>> Well, it compiles this program that Ben posted:
>>>
>>> #include <stdio.h>
>>> #include <math.h>
>>>
>>> int main()
>>> {
>>>       double φ = 0.5, ω2 = 0.2, θ = -0.5, ω3 = 0.1;
>>>       printf("%g\n", cos(φ) * ω2 - sin(θ) * ω3);
>>> }
>>>
>>> (Which uses Greek phi, omega and theta in case they don't come out.)
>>
>> And that parenthetical comment is the very best reason _not_ to use
>> Unicode identifiers in C and C++ programs :-)
> 
> It's (nearly) the third decade of the 21st century.  I take that remark
> as a rebuke to our profession, but also as a prompt to do better.
> 
> You should name and shame your posting software (unless you have
> deliberately configured it to mess up such a well-known character
> encoding).  I hope there is at least an outstanding bug report against
> it.  Of course you may have very good reasons to use old and
> unmaintained (or even unmaintainable) software, but people should still
> know it can't cope with UTF-8.
> 


If I look at my post on Thunderbird, then the letters display correctly, 
as they do on Googlegroups.

The quoting of it in your post and Scott's is messed up on Thunderbird, 
but in Googlegroups, Scott's quote is OK, but your quote of his post 
which includes mine, shows messed up characters instead of the Greek.

Copying and pasting from my Thunderbird post to both MS Word and 
Notepad++ shows the correct glyphs (as it does in Github), but not when 
pasting into SciTe.

So the character information is there. However, copying and pasting from 
your original post, from my Thunderbird, is better behaved. Both seem to 
use the utf-8 charset.

In short, I've no idea what's happening or why, but I'm not really 
surprised as I see this stuff all the time (on TV subtitles too, even 
attempting to show English - things like punctuation mainly).

My low expectations are why I made my comment.

BTW this is a (partial) screen grab of my post as seen on my Thunderbird:

https://github.com/sal55/langs/blob/master/fred.png

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web