• Re: c needs this sign

    From David Brown@3:633/10 to All on Wed Sep 9 13:21:14 2026
    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.


    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From fir@3:633/10 to All on Wed Sep 9 13:33:25 2026
    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 + < | ó
    -------------------------------------------

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Janis Papanagnou@3:633/10 to All on Wed Sep 9 21:37:21 2026
    Subject: 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).


    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From fir@3:633/10 to All on Wed Sep 9 23:59:46 2026
    Janis Papanagnou pisze:

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


    this one is in fact quite nice, and practically could be used as is imo

    char* txt ? "skjnskjns";
    char* txt = "skjnskjns";

    its maybe even better looking than oryginal = but this probably depends
    on font..but from this mentioned it seem the best as for now


    a ? b=3 //would mean assign true to a if b=3

    a=b?3 //this would mean assign b to 3 andcheck if a=3


    hovver im not quite convinced if thise logical 'hypothesis'
    should be cast to arithmetic (maybe yes maybe not i dont know)

    if hypothesis not casted it could mean that if would no need oparators
    at all maybe just syntax

    hypothesis statement

    like

    a<4 print "ssasa"

    0<x<size x ? rand()





    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From fir@3:633/10 to All on Thu Sep 10 00:04:31 2026
    fir pisze:
    Janis Papanagnou pisze:

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


    this one is in fact quite nice, and practically could be used as is imo

    char* txt ? "skjnskjns";
    char* txt = "skjnskjns";

    its maybe even better looking than oryginal = but this probably depends
    on font..but from this mentioned it seem the best as for now


    a ? b=3ÿ //would mean assign true to a if b=3

    a=b?3 //this would mean assign b to 3ÿ andcheck if a=3


    hovver im not quite convinced if thise logical 'hypothesis'
    should be cast to arithmetic (maybe yes maybe not i dont know)

    if hypothesis not casted it could mean that if would no need oparators
    at all maybe just syntax

    hypothesis statement

    like

    a<4 print "ssasa"

    0<x<size x ? rand()





    overally good one

    i may announce

    AS FOR NOW ? IS A WINNER (applause)


    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From fir@3:633/10 to All on Thu Sep 10 00:16:47 2026
    fir pisze:
    fir pisze:
    Janis Papanagnou pisze:

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


    this one is in fact quite nice, and practically could be used as is imo

    char* txt ? "skjnskjns";
    char* txt = "skjnskjns";

    its maybe even better looking than oryginal = but this probably
    depends on font..but from this mentioned it seem the best as for now


    a ? b=3ÿ //would mean assign true to a if b=3

    a=b?3 //this would mean assign b to 3ÿ andcheck if a=3


    hovver im not quite convinced if thise logical 'hypothesis'
    should be cast to arithmetic (maybe yes maybe not i dont know)

    if hypothesis not casted it could mean that if would no need oparators
    at all maybe just syntax

    hypothesis statement

    like

    a<4 print "ssasa"

    0<x<size x ? rand()





    overally good one

    i may announce

    AS FOR NOW ? IS A WINNER (applause)


    as to how to use it on windows there ias a program auto hotkey (3 MB)

    some may instal it, make create new autohotkey script on desktop (text
    file with .ahk extension)

    put this inside this text file

    ^=::SendText("?")


    run it by clicking on it and then this script is run in try area and
    each control + = generates ?

    ??slksklns??sjnskj???sskskjsn


    so practically its not so hard to map unicode on keyboard imo



    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From fir@3:633/10 to All on Thu Sep 10 00:30:52 2026
    fir pisze:
    fir pisze:
    fir pisze:
    Janis Papanagnou pisze:

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


    this one is in fact quite nice, and practically could be used as is imo

    char* txt ? "skjnskjns";
    char* txt = "skjnskjns";

    its maybe even better looking than oryginal = but this probably
    depends on font..but from this mentioned it seem the best as for now


    a ? b=3ÿ //would mean assign true to a if b=3

    a=b?3 //this would mean assign b to 3ÿ andcheck if a=3


    hovver im not quite convinced if thise logical 'hypothesis'
    should be cast to arithmetic (maybe yes maybe not i dont know)

    if hypothesis not casted it could mean that if would no need
    oparators at all maybe just syntax

    hypothesis statement

    like

    a<4 print "ssasa"

    0<x<size x ? rand()





    overally good one

    i may announce

    AS FOR NOW ? IS A WINNER (applause)


    as to how to use it on windows there ias a program auto hotkey (3 MB)

    some may instal it, make create new autohotkey script on desktop (text
    file with .ahk extension)

    put this inside this text file

    ^=::SendText("?")


    run it by clicking on it and then this script is run in try area and
    each control + = generates ?

    ??slksklns??sjnskj???sskskjsn


    so practically its not so hard to map unicode on keyboard imo



    can be also used to map c keywords


    !f::SendText("float ")
    !i::SendText("int ")
    !r::SendText("return ")
    !v::SendText("void ")
    !c::SendText("char ")
    !i::SendText("for(int i=0; i<100; i++) ")


    hero for alts flt+f makes float and so on...
    control+c control+v as copy paste seem to have priority
    so it not showed but alst seem work with no problem
    it may maybe block this menu shortcuts in window but this shortcuts are
    useles for me




    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From bart@3:633/10 to All on Wed Sep 9 23:44:48 2026
    On 09/09/2026 23:04, fir wrote:
    fir pisze:
    Janis Papanagnou pisze:

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


    this one is in fact quite nice, and practically could be used as is imo

    char* txt ? "skjnskjns";
    char* txt = "skjnskjns";

    its maybe even better looking than oryginal = but this probably
    depends on font..but from this mentioned it seem the best as for now


    a ? b=3ÿ //would mean assign true to a if b=3

    a=b?3 //this would mean assign b to 3ÿ andcheck if a=3


    hovver im not quite convinced if thise logical 'hypothesis'
    should be cast to arithmetic (maybe yes maybe not i dont know)

    if hypothesis not casted it could mean that if would no need oparators
    at all maybe just syntax

    hypothesis statement

    like

    a<4 print "ssasa"

    0<x<size x ? rand()





    overally good one

    i may announce

    AS FOR NOW ? IS A WINNER (applause)


    So, what happens now?

    Do you implement this in your enhanced version of C, or in a new
    language (hard)?

    Or persuade someone else to add it to C or some other mainstream
    language (magnitudes harder)?

    Personally I find it near impossible to see, and near impossible to
    type. Still, I added it to my language (which already uses :=) to see
    how it works:

    a := 10
    b ? 20
    c := 30

    It does work, but I have to use Notepad to view it, and even there I
    don't know how to type it: I pasted it from here.

    Visibility is slightly better in Notepad than in Thunderbird, but not by
    much.


    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From fir@3:633/10 to All on Thu Sep 10 00:55:02 2026
    bart pisze:
    On 09/09/2026 23:04, fir wrote:
    fir pisze:
    Janis Papanagnou pisze:

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


    this one is in fact quite nice, and practically could be used as is imo

    char* txt ? "skjnskjns";
    char* txt = "skjnskjns";

    its maybe even better looking than oryginal = but this probably
    depends on font..but from this mentioned it seem the best as for now


    a ? b=3ÿ //would mean assign true to a if b=3

    a=b?3 //this would mean assign b to 3ÿ andcheck if a=3


    hovver im not quite convinced if thise logical 'hypothesis'
    should be cast to arithmetic (maybe yes maybe not i dont know)

    if hypothesis not casted it could mean that if would no need
    oparators at all maybe just syntax

    hypothesis statement

    like

    a<4 print "ssasa"

    0<x<size x ? rand()





    overally good one

    i may announce

    AS FOR NOW ? IS A WINNER (applause)


    So, what happens now?

    Do you implement this in your enhanced version of C, or in a new
    language (hard)?

    Or persuade someone else to add it to C or some other mainstream
    language (magnitudes harder)?

    Personally I find it near impossible to see, and near impossible to
    type. Still, I added it to my language (which already uses :=) to see
    how it works:

    ÿÿÿ a := 10
    ÿÿÿ b ? 20
    ÿÿÿ c := 30

    It does work, but I have to use Notepad to view it, and even there I
    don't know how to type it: I pasted it from here.

    Visibility is slightly better in Notepad than in Thunderbird, but not by much.



    what happans? from all this considered as for all that i see this one
    seems best


    as to adding i dont know last years i dont write my compiler,
    as to imposing also no but i just make a conclusion ;c

    as to typing install auto hot key 2 and you may create new script
    paste it

    ^=::SendText("?")


    as a contest of this script and then control+= will gnerate this

    as to visibility i think its only dependant on which font you use
    for example notepad uses consolas and in this font its look quite good
    for me (as i said imo better than oryginal = )




    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From fir@3:633/10 to All on Thu Sep 10 01:09:25 2026
    fir pisze:
    bart pisze:
    On 09/09/2026 23:04, fir wrote:
    fir pisze:
    Janis Papanagnou pisze:

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


    this one is in fact quite nice, and practically could be used as is imo >>>>
    char* txt ? "skjnskjns";
    char* txt = "skjnskjns";

    its maybe even better looking than oryginal = but this probably
    depends on font..but from this mentioned it seem the best as for now


    a ? b=3ÿ //would mean assign true to a if b=3

    a=b?3 //this would mean assign b to 3ÿ andcheck if a=3


    hovver im not quite convinced if thise logical 'hypothesis'
    should be cast to arithmetic (maybe yes maybe not i dont know)

    if hypothesis not casted it could mean that if would no need
    oparators at all maybe just syntax

    hypothesis statement

    like

    a<4 print "ssasa"

    0<x<size x ? rand()





    overally good one

    i may announce

    AS FOR NOW ? IS A WINNER (applause)


    So, what happens now?

    Do you implement this in your enhanced version of C, or in a new
    language (hard)?

    Or persuade someone else to add it to C or some other mainstream
    language (magnitudes harder)?

    Personally I find it near impossible to see, and near impossible to
    type. Still, I added it to my language (which already uses :=) to see
    how it works:

    ÿÿÿÿ a := 10
    ÿÿÿÿ b ? 20
    ÿÿÿÿ c := 30

    (...)
    as to visibility i think its only dependant on which font you use
    for example notepad uses consolas and in this font its look quite good
    for me (as i said imo better than oryginal = )



    it may be matter of taste , becouse if you like c := 30 you seem to have different taste than i ;c becouse for me its not standable

    for this two in c = and == the set ? and = is much better

    but as i said it very much must depend on font i guess

    (i wouldnt also consider ? as a final choice for assigment but for now
    as for replace in traditional c is best i seen as for the moment

    i myself condider in fact two langueges one is slightly improved c
    (close to traditional c) and one is maybe yet more radically improved c
    and in the second i could maybe search for something more futuristic as assigment, i dont know yet

    but for traditional i may repeat ? = much better than = == andmuch
    better than := =

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From fir@3:633/10 to All on Thu Sep 10 01:21:51 2026
    fir pisze:>>>>
    AS FOR NOW ? IS A WINNER (applause)


    this applaus above i said a bit ironically/distancebecouse its a tiny
    thing, hovever it was long time to
    think about this "= ==" problem ;c

    imo to get to conclusions you need some steps and for
    me some step was noticing equality must be =
    (i forgot at the moment sadly by what ocasion i noticed it)
    (maybe i will recall later, coz i know there was soem occasion)
    if so assigment must be something other byt preferably not much distant
    to = maybe just slightly better - this user janis posted this sign and i checked it looks ok so as for now imo its the best set as for the moment

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From fir@3:633/10 to All on Thu Sep 10 01:36:53 2026
    fir pisze:
    fir pisze:>>>>
    AS FOR NOW ? IS A WINNER (applause)


    this applaus above i said a bit ironically/distancebecouse its a tiny
    thing, hovever it was long time to
    think about this "= ==" problem ;c

    imo to get to conclusions you need some steps and for
    me some step was noticing equality must be =
    (i forgot at the moment sadly by what ocasion i noticed it)
    (maybe i will recall later, coz i know there was soem occasion)
    if so assigment must be something other byt preferably not much distant
    to = maybe just slightly better - this user janis posted this sign and i checked it looks ok so as for now imo its the best set as for the moment


    i dont know if that was the case (probbaly no) when i noticed tah single
    & is mucch better than &&

    dog & cat has some meaning and dog && cat is so much bad as a==2

    may also not e that | as or is also not much fortunate imo

    this | look good as some operator for vector elements 1|2|3 or lists
    maybe, here looks great x|y = foo a|b|c so meybe it should be used
    instead of , in part of cases but not ofr "or"

    not sure if for all "," cases but maybe only some for example
    if foo takes 3 arguments

    foo a b c

    thse arguments will not create vector byt maybe more like ad hoc
    structure and \ should be maybe reserved for plain vectors

    foo x|y - woud mean take a structure-vector of say two ints where
    foo x y maybe take int and int as loose arguments

    maybe that is good way to think

    if so or neds another sign maybe \ is closed for or

    a\b\d //a or b or c





    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From fir@3:633/10 to All on Thu Sep 10 01:45:03 2026
    fir pisze:
    fir pisze:
    fir pisze:>>>>
    AS FOR NOW ? IS A WINNER (applause)


    this applaus above i said a bit ironically/distancebecouse its a tiny
    thing, hovever it was long time to
    think about this "= ==" problem ;c

    imo to get to conclusions you need some steps and for
    me some step was noticing equality must be =
    (i forgot at the moment sadly by what ocasion i noticed it)
    (maybe i will recall later, coz i know there was soem occasion)
    if so assigment must be something other byt preferably not much
    distant to = maybe just slightly better - this user janis posted this
    sign and i checked it looks ok so as for now imo its the best set as
    for the moment


    i dont know if that was the case (probbaly no) when i noticed tah single
    & is mucch better than &&

    dog & cat has some meaning and dog && cat is so much bad as a==2

    may also not e that | as or is also not much fortunate imo

    this | look good as some operator for vector elements 1|2|3 or lists
    maybe, here looks great x|y = foo a|b|c so meybe it should be used
    instead of , in part of cases but not ofr "or"

    not sure if for all "," cases but maybe only some for example
    if foo takes 3 arguments

    foo a b c

    thse arguments will not create vector byt maybe more like ad hoc
    structure and \ should be maybe reserved for plain vectors

    foo x|y - woud mean take a structure-vector of say two ints where
    foo x y maybe take int and int as loose arguments

    maybe that is good way to think

    if so or neds another sign maybe \ is closed for or

    a\b\dÿÿ //a or b or c


    well maybe in fact a|3|2 may be a structure where a 3 2 represent 3 values

    im not sure how it can be fit in c semantics maybe foo 1|2|3
    should pass one pointer to 1|2|3 structure where foo 1 2 3 whould pass 3
    values (not sure though bcouse passing one pointer could evetually show
    to be more eficien than soem syntax would end in being unused thus wasted




    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From David Brown@3:633/10 to All on Thu Sep 10 09:01:58 2026
    Subject: 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).



    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Chris M. Thomasson@3:633/10 to All on Thu Sep 10 13:42:49 2026
    On 9/8/2026 5:29 PM, Lawrence D?Oliveiro wrote:
    On Tue, 8 Sep 2026 11:14:04 +0100, bart wrote:

    Of course this might all be irrelevant in a couple more years when
    everyone uses tools to write code for them.

    Those AI tools are inherently incapable of separating code from data.
    Any programmer will appreciate how this makes them vulnerable to all
    kinds of interesting prompt-injection attacks, which are only getting
    more interesting as time goes on.

    lol. some AI's will try to run code on their end. If you give them a
    payload and a program that uses it in a clever way, perhaps the AI will
    run it on their end. Then again, the code that an AI generates can be
    infected as well.

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Janis Papanagnou@3:633/10 to All on Thu Sep 10 23:13:21 2026
    Subject: 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


    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Keith Thompson@3:633/10 to All on Thu Sep 10 14:54:37 2026
    Subject: 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 */

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Scott Lurndal@3:633/10 to All on Thu Sep 10 22:17:04 2026
    Subject: 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.



    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Keith Thompson@3:633/10 to All on Thu Sep 10 15:48:22 2026
    Subject: 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 */

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Janis Papanagnou@3:633/10 to All on Fri Sep 11 02:03:53 2026
    Subject: 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

    [...]

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Keith Thompson@3:633/10 to All on Thu Sep 10 17:13:57 2026
    Subject: 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 */

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Janis Papanagnou@3:633/10 to All on Fri Sep 11 02:24:40 2026
    Subject: Re: Support of Unicode characters in various places (was Re: c needs this sign)

    On 2026-09-11 02:13, Keith Thompson wrote:
    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!!!

    Yeah, these two are the simple ones; plain amplifications, IMO.
    It's getting more interesting in the difference of mixed forms.
    But, honestly, I don't recall the details any more. Back these
    days I had no computer and the pencil-and-paper-storage-device
    I used has long decayed, I fear.

    ???Or maybe not???

    Better not. (Not here.) :-)

    Janis


    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From David Brown@3:633/10 to All on Fri Sep 11 09:42:45 2026
    Subject: Re: Support of Unicode characters in various places (was Re: c needs this sign)

    On 11/09/2026 02:13, Keith Thompson wrote:
    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???


    PHP has =, ==, and === as different operators, as well as ??. Maybe the
    ??? and !!! are not as unrealistic as they sound !!!



    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From bart@3:633/10 to All on Fri Sep 11 10:51:45 2026
    Subject: 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!)

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From David Brown@3:633/10 to All on Fri Sep 11 12:49:33 2026
    Subject: 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.



    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Scott Lurndal@3:633/10 to All on Fri Sep 11 16:28:06 2026
    Subject: 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.



    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Lawrence D?Oliveiro@3:633/10 to All on Tue Sep 15 07:23:21 2026
    On Wed, 9 Sep 2026 23:44:48 +0100, bart wrote:

    It does work, but I have to use Notepad to view it

    Aren?t you using an OS (Windows NT) which was just about the first to
    embrace Unicode right into its core APIs, back in 1993?

    The fact that it still doesn?t make it easy for you to work natively
    with Unicode text ... just a teentsy weentsy bit of an irony there,
    don?t you think?

    --- PyGate Linux v1.5.19
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)