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

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

c needs this sign

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

Contents

  c needs this sign fir <profesor.fir@gmail.com> - 2026-09-07 15:53 +0200
    Re: c needs this sign David LaRue <huey.dll@tampabay.rr.com> - 2026-09-07 19:21 +0000
      Re: c needs this sign Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-08 01:10 +0200
        Re: c needs this sign Dan Purgert <dan@djph.net> - 2026-09-07 23:13 +0000
          Re: c needs this sign Lane W <cactus_DAC@yahoo.com> - 2026-09-07 17:26 -0600
        Re: c needs this sign David Brown <david.brown@hesbynett.no> - 2026-09-08 10:40 +0200
          Re: c needs this sign Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 10:49 +0200
            Re: c needs this sign David Brown <david.brown@hesbynett.no> - 2026-09-09 13:21 +0200
              Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-09 13:33 +0200
              Support of Unicode characters in various places (was Re: c needs this sign) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 21:37 +0200
                Re: Support of Unicode characters in various places (was Re: c needs this sign) David Brown <david.brown@hesbynett.no> - 2026-09-10 09:01 +0200
                  Re: Support of Unicode characters in various places (was Re: c needs this sign) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-10 23:13 +0200
                    Re: Support of Unicode characters in various places (was Re: c needs this sign) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-10 14:54 -0700
                      Re: Support of Unicode characters in various places (was Re: c needs this sign) scott@slp53.sl.home (Scott Lurndal) - 2026-09-10 22:17 +0000
                        Re: Support of Unicode characters in various places (was Re: c needs this sign) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-10 15:48 -0700
                          Re: Support of Unicode characters in various places (was Re: c needs this sign) bart <bc@freeuk.com> - 2026-09-11 10:51 +0100
                            Re: Support of Unicode characters in various places (was Re: c needs this sign) David Brown <david.brown@hesbynett.no> - 2026-09-11 12:49 +0200
                            Re: Support of Unicode characters in various places (was Re: c needs this sign) scott@slp53.sl.home (Scott Lurndal) - 2026-09-11 16:28 +0000
                      Re: Support of Unicode characters in various places (was Re: c needs this sign) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-11 02:03 +0200
                        Re: Support of Unicode characters in various places (was Re: c needs this sign) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-10 17:13 -0700
                          Re: Support of Unicode characters in various places (was Re: c needs this sign) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-11 02:24 +0200
                          Re: Support of Unicode characters in various places (was Re: c needs this sign) David Brown <david.brown@hesbynett.no> - 2026-09-11 09:42 +0200
            Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-09 23:59 +0200
              Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-10 00:04 +0200
                Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-10 00:16 +0200
                  Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-10 00:30 +0200
                Re: c needs this sign bart <bc@freeuk.com> - 2026-09-09 23:44 +0100
                  Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-10 00:55 +0200
                    Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-10 01:09 +0200
                      Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-10 01:21 +0200
                        Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-10 01:36 +0200
                          Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-10 01:45 +0200
                  Re: c needs this sign Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-15 07:23 +0000
        Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-08 11:56 +0200
          Re: c needs this sign bart <bc@freeuk.com> - 2026-09-08 11:14 +0100
            Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-08 12:28 +0200
            Re: c needs this sign Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-09-08 03:54 -0700
              Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-08 13:13 +0200
              = vs. == (again!) (Was: c needs this sign) gazelle@shell.xmission.com (Kenny McCormack) - 2026-09-08 14:39 +0000
                Re: = vs. == (again!) (Was: c needs this sign) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-14 23:36 -0700
              Re: c needs this sign Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-09-09 11:13 +0200
            Re: c needs this sign Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-09 00:29 +0000
              Re: c needs this sign "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-09-10 13:42 -0700
        Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-08 15:12 +0200
    Re: c needs this sign Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-08 03:33 +0000
      Re: c needs this sign fir <profesor.fir@gmail.com> - 2026-09-08 12:02 +0200
        Re: c needs this sign Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-09 00:27 +0000

Page 1 of 3  [1] 2 3  Next page →

#401688 — c needs this sign

im not sure if in usenet message i am able to draw it but maybe put it 
in some editor that has font where chars are same size

.................
.................
.................
..*************..
..*************..
.................
.................
..*************..
..*************..
..**.............
..**.............
.................


it is like = but with some small line, suggestin it is for assign not for
equality,,, asci dont have it more worse im not sure if even unicode has
it and this is shocking

[toc] | [next] | [standalone]

#401694

fir <profesor.fir@gmail.com> wrote in news:117mfle$3aage$1@dont-email.me:

> im not sure if in usenet message i am able to draw it but maybe put it 
> in some editor that has font where chars are same size
> 
> .................
> .................
> .................
> ..*************..
> ..*************..
> .................
> .................
> ..*************..
> ..*************..
> ..**.............
> ..**.............
> .................
> 
> 
> it is like = but with some small line, suggestin it is for assign not for
> equality,,, asci dont have it more worse im not sure if even unicode has
> it and this is shocking
> 

C doesn't use that character.  Adapt to whatever language you want to use.

You might look at a Forth system and see if you can define the meaning of 
that symbol to do what you want.  Forth allows you to do things like that.

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

#401698

On 2026-09-07 21:21, David LaRue wrote:
> fir <profesor.fir@gmail.com> wrote in news:117mfle$3aage$1@dont-email.me:
> 
>> im not sure if in usenet message i am able to draw it but maybe put it
>> in some editor that has font where chars are same size
>>
>> .................
>> .................
>> .................
>> ..*************..
>> ..*************..
>> .................
>> .................
>> ..*************..
>> ..*************..
>> ..**.............
>> ..**.............
>> .................
>>
>>
>> it is like = but with some small line, suggestin it is for assign not for
>> equality,,, asci dont have it more worse im not sure if even unicode has
>> it and this is shocking

I'm lacking context why you need that, for what you need that, what it
is supposed to mean - differentiate assignment from equality; is that
what you tried to express? - and why it's non-existence is "shocking".

To find characters by a (hand-painted) glyph you can use this service:
https://shapecatcher.com/

If you dislike C's '==' for equality, and '=' for assignment, so much
that you continue your whining and get even mentally shocked I affirm
the previously given suggestion to just switch language (and newsgroup).

(There's many other languages that made (IMO) better choices than "C"
concerning these operators/operations. Often there's ':=' used for the
assignment and '=' for equality. Or there's context dependent parsing
and interpretation of the '=' symbol.)

It's your choice.

Janis

BTW, I see that in Unicode there seems to be "Colon equals" '≔'
(Unicode hexadecimal: 0x2254, In block: Mathematical Operators),
which resembles the common two-character assignment symbol ':=',
but depending on the font it's hard to recognize. - And it's not
common or guaranteed that languages support Unicode characters,
let alone as part of the basic language definition.

>>
> 
> C doesn't use that character.  Adapt to whatever language you want to use.
> 
> You might look at a Forth system and see if you can define the meaning of
> that symbol to do what you want.  Forth allows you to do things like that.

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

#401699

On 2026-09-07, Janis Papanagnou wrote:
> On 2026-09-07 21:21, David LaRue wrote:
>> fir <profesor.fir@gmail.com> wrote in news:117mfle$3aage$1@dont-email.me:
>> 
>>> im not sure if in usenet message i am able to draw it but maybe put it
>>> in some editor that has font where chars are same size
>>>
>>> .................
>>> .................
>>> .................
>>> ..*************..
>>> ..*************..
>>> .................
>>> .................
>>> ..*************..
>>> ..*************..
>>> ..**.............
>>> ..**.............
>>> .................
>>>
>>>
>>> it is like = but with some small line, suggestin it is for assign not for
>>> equality,,, asci dont have it more worse im not sure if even unicode has
>>> it and this is shocking
>
> I'm lacking context why you need that, for what you need that, what it
> is supposed to mean - differentiate assignment from equality; is that
> what you tried to express? - and why it's non-existence is "shocking".

I think fir just needs something new to complain about.

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

#401700

Dan Purgert wrote:
> On 2026-09-07, Janis Papanagnou wrote:
>> On 2026-09-07 21:21, David LaRue wrote:
>>> fir <profesor.fir@gmail.com> wrote in news:117mfle$3aage$1@dont-email.me:
>>>
>>>> im not sure if in usenet message i am able to draw it but maybe put it
>>>> in some editor that has font where chars are same size
>>>>
>>>> .................
>>>> .................
>>>> .................
>>>> ..*************..
>>>> ..*************..
>>>> .................
>>>> .................
>>>> ..*************..
>>>> ..*************..
>>>> ..**.............
>>>> ..**.............
>>>> .................
>>>>
>>>>
>>>> it is like = but with some small line, suggestin it is for assign not for
>>>> equality,,, asci dont have it more worse im not sure if even unicode has
>>>> it and this is shocking
>>
>> I'm lacking context why you need that, for what you need that, what it
>> is supposed to mean - differentiate assignment from equality; is that
>> what you tried to express? - and why it's non-existence is "shocking".
> 
> I think fir just needs something new to complain about.
> 
If he would just discover C# he would find everything at his fingertips. 
C++ is fatally flawed.

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

#401710

On 08/09/2026 01:10, Janis Papanagnou wrote:
> On 2026-09-07 21:21, David LaRue wrote:
>> fir <profesor.fir@gmail.com> wrote in news:117mfle$3aage$1@dont-email.me:
>>
>>> im not sure if in usenet message i am able to draw it but maybe put it
>>> in some editor that has font where chars are same size
>>>
>>> .................
>>> .................
>>> .................
>>> ..*************..
>>> ..*************..
>>> .................
>>> .................
>>> ..*************..
>>> ..*************..
>>> ..**.............
>>> ..**.............
>>> .................
>>>
>>>
>>> it is like = but with some small line, suggestin it is for assign not 
>>> for
>>> equality,,, asci dont have it more worse im not sure if even unicode has
>>> it and this is shocking
> 
> I'm lacking context why you need that, for what you need that, what it
> is supposed to mean - differentiate assignment from equality; is that
> what you tried to express? - and why it's non-existence is "shocking".
> 

It is not always easy to tell with fir, but I believe he thought it was 
shocking that this symbol is not in Unicode.  I have no idea what this 
symbol is supposed to be, or where he has taken it from, or what he 
thinks it should mean.  But if it is not in Unicode, then that is a good 
indication that it would be a very poor choice for anything as it would 
be unfamiliar to everyone else.  And it would be impossible to type when 
coding.

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

#401768

On 2026-09-08 10:40, David Brown wrote:
>> [...]
> 
> It is not always easy to tell with fir, but I believe he thought it was 
> shocking that this symbol is not in Unicode.  I have no idea what this 
> symbol is supposed to be, or where he has taken it from, or what he 
> thinks it should mean.  But if it is not in Unicode, then that is a good 
> indication that it would be a very poor choice for anything as it would 
> be unfamiliar to everyone else.  And it would be impossible to type when 
> coding.

I think that this is actually the crucial point; how to type Unicode
symbols *efficiently* on a typical keyboard.

Concerning the "Colon equals" '≔' I mentioned, I mean, why not just
use ':=' as usual. The Unicode symbol adds nothing and costs a lot!

Incidentally there were legacy keyboards that supported characters
that we now typically find only in Unicode and some legacy languages
even supported these.

I don't see a point in using non-portable or exotic characters that
are not easy to handle.

Janis

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

#401778

On 09/09/2026 10:49, Janis Papanagnou wrote:
> On 2026-09-08 10:40, David Brown wrote:
>>> [...]
>>
>> It is not always easy to tell with fir, but I believe he thought it 
>> was shocking that this symbol is not in Unicode.  I have no idea what 
>> this symbol is supposed to be, or where he has taken it from, or what 
>> he thinks it should mean.  But if it is not in Unicode, then that is a 
>> good indication that it would be a very poor choice for anything as it 
>> would be unfamiliar to everyone else.  And it would be impossible to 
>> type when coding.
> 
> I think that this is actually the crucial point; how to type Unicode
> symbols *efficiently* on a typical keyboard.
> 
> Concerning the "Colon equals" '≔' I mentioned, I mean, why not just
> use ':=' as usual. The Unicode symbol adds nothing and costs a lot!
> 
> Incidentally there were legacy keyboards that supported characters
> that we now typically find only in Unicode and some legacy languages
> even supported these.
> 
> I don't see a point in using non-portable or exotic characters that
> are not easy to handle.
> 

Yes.

At the very least, they should add something very significant to the 
language before using them.  People may want to use letters from their 
own language for identifiers, and that is not unreasonable (though it is 
a decision that may cause them complications later) since it adds to 
their own understanding, and is relatively easy to type on their own 
keyboards.  (Sometimes people have to switch keyboard layouts to do so.) 
  A Norwegian speaker will see "for", "før" and "fôr" as three very 
different words, and all are easy to type on a Norwegian layout 
keyboard.  So a Norwegian programmer might conceivably choose to use 
these Norwegian letters in their code.

So if you were making a language that was heavily oriented towards 
vectors and matrices, you /might/ feel it is worth having · and × as 
special symbols for distinguishing dot product and cross product.  But 
you would not want them for normal every-day usage in a general-purpose 
language.  And you would not, as you say, use a ≔ when := is clearer and 
easier to type.

And of course, easy to type varies by user.  I have immediate access to 
π, ÷, ², ≤ and many other symbols - people with other OS's or other 
keyboard layouts may not be so lucky.

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

#401781

David Brown pisze:
> On 09/09/2026 10:49, Janis Papanagnou wrote:
>> On 2026-09-08 10:40, David Brown wrote:
>>>> [...]
>>>
>>> It is not always easy to tell with fir, but I believe he thought it 
>>> was shocking that this symbol is not in Unicode.  I have no idea what 
>>> this symbol is supposed to be, or where he has taken it from, or what 
>>> he thinks it should mean.  But if it is not in Unicode, then that is 
>>> a good indication that it would be a very poor choice for anything as 
>>> it would be unfamiliar to everyone else.  And it would be impossible 
>>> to type when coding.
>>
>> I think that this is actually the crucial point; how to type Unicode
>> symbols *efficiently* on a typical keyboard.
>>
>> Concerning the "Colon equals" '≔' I mentioned, I mean, why not just
>> use ':=' as usual. The Unicode symbol adds nothing and costs a lot!
>>
>> Incidentally there were legacy keyboards that supported characters
>> that we now typically find only in Unicode and some legacy languages
>> even supported these.
>>
>> I don't see a point in using non-portable or exotic characters that
>> are not easy to handle.
>>
> 
> Yes.
> 
> At the very least, they should add something very significant to the 
> language before using them.  People may want to use letters from their 
> own language for identifiers, and that is not unreasonable (though it is 
> a decision that may cause them complications later) since it adds to 
> their own understanding, and is relatively easy to type on their own 
> keyboards.  (Sometimes people have to switch keyboard layouts to do so.) 
>   A Norwegian speaker will see "for", "før" and "fôr" as three very 
> different words, and all are easy to type on a Norwegian layout 
> keyboard.  So a Norwegian programmer might conceivably choose to use 
> these Norwegian letters in their code.
> 
> So if you were making a language that was heavily oriented towards 
> vectors and matrices, you /might/ feel it is worth having · and × as 
> special symbols for distinguishing dot product and cross product.  But 
> you would not want them for normal every-day usage in a general-purpose 
> language.  And you would not, as you say, use a ≔ when := is clearer and 
> easier to type.
> 
> And of course, easy to type varies by user.  I have immediate access to 
> π, ÷, ², ≤ and many other symbols - people with other OS's or other 
> keyboard layouts may not be so lucky.
> 

its trivial to add extensions in code editor (if the sign is in unicode )

its alos thivial to add it be configurable in aditor like you got line 
in a grid like
------------------------------------------
control+2   | ²
-------------------------------------------
control+p   | π
-------------------------------------------
control + < | ≤
-------------------------------------------

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

#401834 — Support of Unicode characters in various places (was Re: c needs this sign)

On 2026-09-09 13:21, David Brown wrote:
> On 09/09/2026 10:49, Janis Papanagnou wrote:
>>
>> [ general or nationally uncommon Unicode characters in IT ]
> 
> Yes.
> 
> At the very least, they should add something very significant to the 
> language before using them.  People may want to use letters from their 
> own language for identifiers, and that is not unreasonable (though it is 
> a decision that may cause them complications later) since it adds to 
> their own understanding, and is relatively easy to type on their own 
> keyboards.

Yes, though I am ambivalent here. - I see three levels of national
language characters support:
  - user data (text entities for general I/O to/from the users)
  - national program identifiers (some languages support that)
  - support for national language keywords (cf. Algol 68, e.g.)

The first one is, I think, a necessity nowadays.
The last one is probably overkill and usually not supported by common
programming languages; but I also see a point specifically in cultures
that have their own alphabet where it may be considered very useful
(e.g. Russian, Indian, or Chinese, just to name some cultures/markets).
And the mid point, the "identifiers", well; in international projects
that might be counterproductive. - But as said, I'm ambivalent here.

Mind that it looks somewhat strange, it's peculiar to read, if you
have keywords in English and the entities in between in your national
language. Myself I occasionally tried that but often resorted to the
unique use of the English language. Compare the variants

   if is_prime (value) then ...         all consistent in English
   if ist_primzahl (wert) then ...      peculiar mixed language
   wenn primzahl (wert) dann ...        widely unsupported

In some contexts we also used a mixed approach concerning identifiers.
High-level identifiers were written in German to reflect the entities
in the requirements and specification documents - this proved really
helpful! - and technical low-level identifiers were in English. That
may sound strange but it worked pretty well (despite its peculiarity).

> (Sometimes people have to switch keyboard layouts to do so.) 
>   A Norwegian speaker will see "for", "før" and "fôr" as three very 
> different words, and all are easy to type on a Norwegian layout 
> keyboard.  So a Norwegian programmer might conceivably choose to use 
> these Norwegian letters in their code.
> 
> So if you were making a language that was heavily oriented towards 
> vectors and matrices, you /might/ feel it is worth having · and × as 
> special symbols for distinguishing dot product and cross product. 

As a specific fixed language built-in that would be problematic for an
internationally used language.

Another option, not as strongly connected to the language, would be to
have language support for defining operators (but in a more flexible
way than, say, C++ allows it[*]).

> But 
> you would not want them for normal every-day usage in a general-purpose 
> language.  And you would not, as you say, use a ≔ when := is clearer and 
> easier to type.
> 
> And of course, easy to type varies by user.  I have immediate access to 
> π, ÷, ², ≤ and many other symbols - people with other OS's or other 
> keyboard layouts may not be so lucky.

Yes, I can also create some subset of Unicode characters by using the
"Alt Gr" Key. But language definitions should ideally not be relying on
national specifics or hardware specifics.

Janis

[*] In Algol 68 I could define "OP XPROD", or "OP *" (depending on the
actual types), or "OP <somesym>" (where <somesym> is a fitting symbol,
maybe just 'X' or so - but there it has to be a "worthy character" and
the Algol 68 Genie interpreter doesn't seem to like Unicode operators,
or other program entities in Unicode. But I/O of such characters is at
least fine).

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

#401868 — Re: Support of Unicode characters in various places (was Re: c needs this sign)

On 09/09/2026 21:37, Janis Papanagnou wrote:
> On 2026-09-09 13:21, David Brown wrote:
>> On 09/09/2026 10:49, Janis Papanagnou wrote:
>>>
>>> [ general or nationally uncommon Unicode characters in IT ]
>>
>> Yes.
>>
>> At the very least, they should add something very significant to the 
>> language before using them.  People may want to use letters from their 
>> own language for identifiers, and that is not unreasonable (though it 
>> is a decision that may cause them complications later) since it adds 
>> to their own understanding, and is relatively easy to type on their 
>> own keyboards.
> 
> Yes, though I am ambivalent here. - I see three levels of national
> language characters support:
>   - user data (text entities for general I/O to/from the users)

Yes - that is very useful.  (In C, that is the "execution character 
set".)  These days that usually means UTF-8 as the main choice, but 
legacy coding can use Latin-9, UTF-16, or a few others.

>   - national program identifiers (some languages support that)

I think most modern programming languages support that - including C99. 
I don't think they are commonly used in practice, but they are supported.

>   - support for national language keywords (cf. Algol 68, e.g.)

Algol 68, AIUI, also had a number of special symbols as operators.  It 
was not at the level of APL, however!  I don't think the obligatory use 
of non-ASCII characters caught on in other programming languages, nor do 
many others have localised translations of keywords or standard 
identifiers.  (VB Macros and spreadsheet functions in MS Office can be 
nationalised, I think.)

> 
> The first one is, I think, a necessity nowadays.
> The last one is probably overkill and usually not supported by common
> programming languages; but I also see a point specifically in cultures
> that have their own alphabet where it may be considered very useful
> (e.g. Russian, Indian, or Chinese, just to name some cultures/markets).
> And the mid point, the "identifiers", well; in international projects
> that might be counterproductive. - But as said, I'm ambivalent here.
> 
> Mind that it looks somewhat strange, it's peculiar to read, if you
> have keywords in English and the entities in between in your national
> language. Myself I occasionally tried that but often resorted to the
> unique use of the English language. Compare the variants
> 
>    if is_prime (value) then ...         all consistent in English
>    if ist_primzahl (wert) then ...      peculiar mixed language
>    wenn primzahl (wert) dann ...        widely unsupported
> 

Usually mixing languages (or writing systems) increases cognitive load, 
and that's never a good idea.  But sometimes you only really know the 
word or term in one non-English language, or the word may not have a 
sensible translation to English - using the original term in identifiers 
can be easier than trying to invent some word in English.  How often 
this occurs will of course depend on the kind of programming you are doing.

> In some contexts we also used a mixed approach concerning identifiers.
> High-level identifiers were written in German to reflect the entities
> in the requirements and specification documents - this proved really
> helpful! - and technical low-level identifiers were in English. That
> may sound strange but it worked pretty well (despite its peculiarity).
> 

I can understand that.

>> (Sometimes people have to switch keyboard layouts to do so.)   A 
>> Norwegian speaker will see "for", "før" and "fôr" as three very 
>> different words, and all are easy to type on a Norwegian layout 
>> keyboard.  So a Norwegian programmer might conceivably choose to use 
>> these Norwegian letters in their code.
>>
>> So if you were making a language that was heavily oriented towards 
>> vectors and matrices, you /might/ feel it is worth having · and × as 
>> special symbols for distinguishing dot product and cross product. 
> 
> As a specific fixed language built-in that would be problematic for an
> internationally used language.
> 

There needs to be some kind of "plan B" for people without easy access 
to the characters.  Trigraphs have been used, but they are a very messy 
solution - you are replacing a (presumably) clear symbol with multiple 
unclear ones.  A <iso646.h> style is better, where someone lacking a ^ 
key can write "xor" instead.

> Another option, not as strongly connected to the language, would be to
> have language support for defining operators (but in a more flexible
> way than, say, C++ allows it[*]).

Yes.  (C++ lets you make definitions for overloads of existing 
operators, but it does not let you make your own operators.  Haskell and 
Forth are examples of languages that support user-defined operators.)

> 
>> But you would not want them for normal every-day usage in a general- 
>> purpose language.  And you would not, as you say, use a ≔ when := is 
>> clearer and easier to type.
>>
>> And of course, easy to type varies by user.  I have immediate access 
>> to π, ÷, ², ≤ and many other symbols - people with other OS's or other 
>> keyboard layouts may not be so lucky.
> 
> Yes, I can also create some subset of Unicode characters by using the
> "Alt Gr" Key. But language definitions should ideally not be relying on
> national specifics or hardware specifics.
> 

The more general the audience, the more you have to target the lowest 
common denominator.  So a language specification or standard library 
should not use non-ASCII characters unless the advantage is huge.  As 
you get closer to the final programmer, you can be more flexible.  So a 
library specifically designed to parse Greek text might reasonably use 
Greek letters.  And the final programmer is going to do what he wants, 
regardless of anyone's rules or recommendations!

> Janis
> 
> [*] In Algol 68 I could define "OP XPROD", or "OP *" (depending on the
> actual types), or "OP <somesym>" (where <somesym> is a fitting symbol,
> maybe just 'X' or so - but there it has to be a "worthy character" and
> the Algol 68 Genie interpreter doesn't seem to like Unicode operators,
> or other program entities in Unicode. But I/O of such characters is at
> least fine).
> 

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

#401914 — Re: Support of Unicode characters in various places (was Re: c needs this sign)

On 2026-09-10 09:01, David Brown wrote:
> On 09/09/2026 21:37, Janis Papanagnou wrote:
> [...]
>>   - national program identifiers (some languages support that)
> 
> I think most modern programming languages support that - including C99. 
> I don't think they are commonly used in practice, but they are supported.

Frankly, I cannot tell. I know just a small subset of the "modern
languages".

But if I just try, for example, my shell I see that while Kornshell
seems to support that the (nowadays more widely used) Bash does not.
Awk (in its form of the active and maintained GNU Awk) also doesn't
support it.

> 
>>   - support for national language keywords (cf. Algol 68, e.g.)
> 
> Algol 68, AIUI, also had a number of special symbols as operators. 

I'm not sure what you mean by that.

(In Algol 68 you have many standard operators, as symbols and names,
and you have the option to define own operators by overloading the
existing operator symbols and names for new argument types, and also
by defining own new operators by new symbols and symbol combinations
(there's some restrictions here, though), or by arbitrary new operator
names.

Specific characters (like the multiplication char 'x') may have been
supported on a platform but I don't see that they would have worked
in a portable way on other systems that didn't support that character.

> [...]
>> [...]
> 
> Usually mixing languages (or writing systems) increases cognitive load,

Yes.

> and that's never a good idea. 

(But see example quoted below.)

> But sometimes you only really know the 
> word or term in one non-English language, or the word may not have a 
> sensible translation to English - using the original term in identifiers 
> can be easier than trying to invent some word in English. 

I think it's depending on the actual semantics of the respective word.
Low level there's IMO rarely needed to use ones native language. High
level, where you describe the actual real-life entities, it makes much
more sense! (I.e. to not translate the terms to the lingua franca.)

> How often 
> this occurs will of course depend on the kind of programming you are doing.
> 
>> In some contexts we also used a mixed approach concerning identifiers.
>> High-level identifiers were written in German to reflect the entities
>> in the requirements and specification documents - this proved really
>> helpful! - and technical low-level identifiers were in English. That
>> may sound strange but it worked pretty well (despite its peculiarity).
> 
> I can understand that.

>> [...]
> 
> There needs to be some kind of "plan B" for people without easy access 
> to the characters.  Trigraphs have been used, but they are a very messy 
> solution - you are replacing a (presumably) clear symbol with multiple 
> unclear ones. 

I've yet to hear that anyone actually used trigraphs. - Weren't they,
because of that, even removed from recent "C" (or C++) standards?

> A <iso646.h> style is better, where someone lacking a ^ 
> key can write "xor" instead.

I don't know what the <iso646.h> header actually is. - The "problem"
with "ISO 646" is that there's many (national) variants of it. - If
we're speaking about the ISO 646 IRV (International Reference Version)
there's a '^' available at least. (Which doesn't mean it's available
on specific national keyboards, though.)

But generally I'd think the ISO 646 IRV would be (widely) sensible as
base for writing programs [in programming languages that are typically
defined in the western cultures].

> 
>> Another option, not as strongly connected to the language, would be to
>> have language support for defining operators (but in a more flexible
>> way than, say, C++ allows it[*]).
> 
> Yes.  (C++ lets you make definitions for overloads of existing 
> operators, but it does not let you make your own operators.  Haskell and 
> Forth are examples of languages that support user-defined operators.)

(As Algol 68.)

>> [...]
> 
> The more general the audience, the more you have to target the lowest 
> common denominator. [...]

Yes, that's the essence.

Janis

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

#401918 — Re: Support of Unicode characters in various places (was Re: c needs this sign)

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
> I've yet to hear that anyone actually used trigraphs. - Weren't they,
> because of that, even removed from recent "C" (or C++) standards?

I've used trigraphs, but only in deliberately obfuscated code.  I'm not
aware of any code that uses trigraphs because they're useful.

Part of the point of trigraphs was to enable the use of C on
EBCDIC-based systems that don't have all the characters C requires,
including '{' and '}'.  (There are EBCDIC code pages that do have those
characters, but they're outside the "invariant subset".)

It's possible that trigraphs have been used accidentally more often
than they've been used intentionally:

    fprintf(stderr, "What the heck just happened??!\n");

Even more fun (though this is deliberately contrived, not accidental)
(??/ expands to \) :

#include <stdio.h>
int main(void) {
    // Is this a multi-line comment ??/
    if (1) puts("No, it isn't."); else
    puts("Yes, it is.");
}

Yes, trigraphs were removed in the C23 standard.  (C++ removed them
in C++17.)

>> A <iso646.h> style is better, where someone lacking a ^ key can
>> write "xor" instead.
>
> I don't know what the <iso646.h> header actually is. - The "problem"
> with "ISO 646" is that there's many (national) variants of it. - If
> we're speaking about the ISO 646 IRV (International Reference Version)
> there's a '^' available at least. (Which doesn't mean it's available
> on specific national keyboards, though.)

<iso646.h> is a standard header, introduced in the 1995 amendment
to the C90 standard.  It defines 11 macros, intended for use on
systems that use character sets that *aren't* compatible with ISO
646 (basically 7-bit ASCII), or at least that make it difficult
to use certain ASCII characters.  The macros are:

#define and    &&
#define and_eq &=
#define bitand &
#define bitor  |
#define compl  ~
#define not    !
#define not_eq !=
#define or     ||
#define or_eq  |=
#define xor    ^
#define xor_eq ^=

In my experience, they're rarely used.

C95 also added *digraphs*, alternate spellings of certain tokens:

<:     [
:>     ]
<%     {
%>     }
%:     #
%:%:   ##

<iso646.h> and digraphs operate on the token level.  Trigraphs are
(were) replaced in translation phase 1, so they can be used in
character constants, string literals, header names, comments,
and so forth.

Presumably there are still C programmers who develop on ECBDIC-based
systems.  I don't know what solutions they typically use for required
characters that aren't supported.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#401920 — Re: Support of Unicode characters in various places (was Re: c needs this sign)

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>[...]
>> I've yet to hear that anyone actually used trigraphs. - Weren't they,
>> because of that, even removed from recent "C" (or C++) standards?
>
>I've used trigraphs, but only in deliberately obfuscated code.  I'm not
>aware of any code that uses trigraphs because they're useful.
>
>Part of the point of trigraphs was to enable the use of C on
>EBCDIC-based systems that don't have all the characters C requires,
>including '{' and '}'.  (There are EBCDIC code pages that do have those
>characters, but they're outside the "invariant subset".)

The other part may have been for those still using ASR-33 teletypes
which were missing several characters required in C, including
curly braces, vertical bar, backtick and tilde.

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

#401922 — Re: Support of Unicode characters in various places (was Re: c needs this sign)

scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>[...]
>>> I've yet to hear that anyone actually used trigraphs. - Weren't they,
>>> because of that, even removed from recent "C" (or C++) standards?
>>
>>I've used trigraphs, but only in deliberately obfuscated code.  I'm not
>>aware of any code that uses trigraphs because they're useful.
>>
>>Part of the point of trigraphs was to enable the use of C on
>>EBCDIC-based systems that don't have all the characters C requires,
>>including '{' and '}'.  (There are EBCDIC code pages that do have those
>>characters, but they're outside the "invariant subset".)
>
> The other part may have been for those still using ASR-33 teletypes
> which were missing several characters required in C, including
> curly braces, vertical bar, backtick and tilde.

Apparently the ASR-33 generated 7-bit ASCII, but didn't support
lowercase letters.

The stty command had (and still has, at least in some versions)
options to map uppercase characters to lowercase, and to generate
uppercase with a '\' prefix, so Hello would be entered as \HELLO.
I suppose a C programmer would likely be using a line editor like
"ed" to edit code, which would be subject to the current tty
settings, and since C is mostly lowercase the translation would
make it tolerable.

I wonder how many ASR-33s were still in use for C development by
the time <iso646.h> and trigraphs were introduced in 1995.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#401936 — Re: Support of Unicode characters in various places (was Re: c needs this sign)

On 10/09/2026 23:48, Keith Thompson wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>> [...]
>>>> I've yet to hear that anyone actually used trigraphs. - Weren't they,
>>>> because of that, even removed from recent "C" (or C++) standards?
>>>
>>> I've used trigraphs, but only in deliberately obfuscated code.  I'm not
>>> aware of any code that uses trigraphs because they're useful.
>>>
>>> Part of the point of trigraphs was to enable the use of C on
>>> EBCDIC-based systems that don't have all the characters C requires,
>>> including '{' and '}'.  (There are EBCDIC code pages that do have those
>>> characters, but they're outside the "invariant subset".)
>>
>> The other part may have been for those still using ASR-33 teletypes
>> which were missing several characters required in C, including
>> curly braces, vertical bar, backtick and tilde.


(Where does C require backtick?)

> Apparently the ASR-33 generated 7-bit ASCII, but didn't support
> lowercase letters.
> 
> The stty command had (and still has, at least in some versions)
> options to map uppercase characters to lowercase, and to generate
> uppercase with a '\' prefix, so Hello would be entered as \HELLO.
> I suppose a C programmer would likely be using a line editor like
> "ed" to edit code, which would be subject to the current tty
> settings, and since C is mostly lowercase the translation would
> make it tolerable.
> 
> I wonder how many ASR-33s were still in use for C development by
> the time <iso646.h> and trigraphs were introduced in 1995.
> 

I used ASR33s and other terminals with various limitations from 1976. 
The first computer I /made/ used 6-bit (I think, ASCII codes 32 to 95 
offset to be 0 to 63, so upper-case only), in 1981.

How did people even write C on such systems? Given that much of it /had/ 
to be lower-case. It must have looked appalling. (I didn't think it 
looked that great anyway!)

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

#401938 — Re: Support of Unicode characters in various places (was Re: c needs this sign)

On 11/09/2026 11:51, bart wrote:
> On 10/09/2026 23:48, Keith Thompson wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>>> [...]
>>> The other part may have been for those still using ASR-33 teletypes
>>> which were missing several characters required in C, including
>>> curly braces, vertical bar, backtick and tilde.
> 
> 
> (Where does C require backtick?)

It was added to the required source and execution character set in C23 
(along with @ and $), though I don't believe it has any specific use in 
the language.  @ has no specific use either, while $ may be an 
additional implementation-defined "letter" in identifiers.  I guess it 
was just added to the list of required characters while tidying up with 
the removal of trigraphs, as these are characters that people can find 
useful and which are present in any real-world C implementation.

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

#401962 — Re: Support of Unicode characters in various places (was Re: c needs this sign)

bart <bc@freeuk.com> writes:
>On 10/09/2026 23:48, Keith Thompson wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>>> [...]
>>>>> I've yet to hear that anyone actually used trigraphs. - Weren't they,
>>>>> because of that, even removed from recent "C" (or C++) standards?
>>>>
>>>> I've used trigraphs, but only in deliberately obfuscated code.  I'm not
>>>> aware of any code that uses trigraphs because they're useful.
>>>>
>>>> Part of the point of trigraphs was to enable the use of C on
>>>> EBCDIC-based systems that don't have all the characters C requires,
>>>> including '{' and '}'.  (There are EBCDIC code pages that do have those
>>>> characters, but they're outside the "invariant subset".)
>>>
>>> The other part may have been for those still using ASR-33 teletypes
>>> which were missing several characters required in C, including
>>> curly braces, vertical bar, backtick and tilde.
>
>
>(Where does C require backtick?)
>
>> Apparently the ASR-33 generated 7-bit ASCII, but didn't support
>> lowercase letters.
>> 
>> The stty command had (and still has, at least in some versions)
>> options to map uppercase characters to lowercase, and to generate
>> uppercase with a '\' prefix, so Hello would be entered as \HELLO.
>> I suppose a C programmer would likely be using a line editor like
>> "ed" to edit code, which would be subject to the current tty
>> settings, and since C is mostly lowercase the translation would
>> make it tolerable.
>> 
>> I wonder how many ASR-33s were still in use for C development by
>> the time <iso646.h> and trigraphs were introduced in 1995.
>> 
>
>I used ASR33s and other terminals with various limitations from 1976. 
>The first computer I /made/ used 6-bit (I think, ASCII codes 32 to 95 
>offset to be 0 to 63, so upper-case only), in 1981.
>
>How did people even write C on such systems?

Did you read what you replied to?  The Unix systems that most
C programmers were using had a terminal driver that would
translate upper-case to lower-case automatically, if so
configured.  The stty(1) command was used to change terminal
driver confgurations.   The login(1) command would automatically
set that flag if the username was typed in upper-case.

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

#401928 — Re: Support of Unicode characters in various places (was Re: c needs this sign)

On 2026-09-10 23:54, Keith Thompson wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> [...]
> 
> It's possible that trigraphs have been used accidentally more often
> than they've been used intentionally:
> 
>      fprintf(stderr, "What the heck just happened??!\n");

LOL! - That's really great; you made my day!  8-)

It never occurred to me that you may stumble into such a case.
(Luckily the default settings of my compiler warns about it.)

(BTW, in my youth I had specified some detailed semantics (and
connotations) for the textual multiplication of '?' and '!' up
to a length of 3 - it had not been common to express more than
expressible with the single signs. I considered it worthy since
the expressive power of plain '!' and '?' wasn't sufficient for
the finer tones.)

> 
> Even more fun (though this is deliberately contrived, not accidental)
> (??/ expands to \) :
> 
> #include <stdio.h>
> int main(void) {
>      // Is this a multi-line comment ??/
>      if (1) puts("No, it isn't."); else
>      puts("Yes, it is.");
> }

Yeah, some features just invite to do fancy things. :-)

> 
> Yes, trigraphs were removed in the C23 standard.  (C++ removed them
> in C++17.)
> 
>>> A <iso646.h> style is better, where someone lacking a ^ key can
>>> write "xor" instead.
>>
>> I don't know what the <iso646.h> header actually is. - [...]
> 
> <iso646.h> is a standard header, introduced in the 1995 amendment
> to the C90 standard.  It defines 11 macros, intended for use on
> systems that use character sets that *aren't* compatible with ISO
> 646 (basically 7-bit ASCII), or at least that make it difficult
> to use certain ASCII characters. [...]

Aha. Thanks.

> [...]
> 
> <iso646.h> and digraphs operate on the token level.  Trigraphs are
> (were) replaced in translation phase 1, so they can be used in
> character constants, string literals, header names, comments,
> and so forth.

Interesting. Thanks.

Janis

> [...]

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

#401930 — Re: Support of Unicode characters in various places (was Re: c needs this sign)

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
> (BTW, in my youth I had specified some detailed semantics (and
> connotations) for the textual multiplication of '?' and '!' up
> to a length of 3 - it had not been common to express more than
> expressible with the single signs. I considered it worthy since
> the expressive power of plain '!' and '?' wasn't sufficient for
> the finer tones.)

Really???  Tell me more!!!

⸘⸘⸘Or maybe not‽‽‽

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web