legal UTF-8 characters in Identifiers ?

[Jason Vas Dias]

Good day -

I'd really like to be able to define functions with names like :
∀() (\U{FOR_ALL}), or ⭮() , or ⭯() , or :
8704 2200 (1 1) ∀ 'FOR ALL'
8705 2201 (1 1) ∁ 'COMPLEMENT'
8707 2203 (1 1) ∃ 'THERE EXISTS'
8708 2204 (1 1) ∄ 'THERE DOES NOT EXIST'

Why can't I use these characters in identifiers ?

Would there be any support for submitting an RFC to the standards groups
to allow implementations to have some sort of local UTF-8 character
white-list policy ?

ie. I'd like to develop extensions for GCC and Clang that will allow them
to load a UTF-8 character White-List file , then these characters would be
allowed regardless of what the standards say about valid identifier characters.

Next step is getting a complete dump of what GCC and Clang consider to
be valid UTF-8 identifier characters, which is not as straightforward as it
should be.

I'd most appreciate any helpful advice / informative comments.

Thanks & Best Regards,
Jason

[Richard Damon]

My understanding is that C++ basically just took the set of characters
for identifiers from the recommendation of the Unicode Standard for
"Identifiers" (XID_Start, XID_Continue). All the characters you
mentioned are defined (I beleive) as operators.

My one thought is that the Standard Committee wants to reserve the
operators from being identifies in case at some point a method is
defined to add new operators.

My guess is that GCC and Clang just implement the set defined by the
standard, which means going to the UNICODE standard that is applicable
for that compiler and looking at its definition of those classes. I
wouldn't be surprised if the build process just has as an input, the
Unicode class definition file, and a program that parses it to build the
needed code for the various things that need that information.

Of course, there is nothing to prevent an implementation from accepting
additional characters (possibly with a warning or an option) beyond the
defined set.

[Scott Lurndal]

Actually, there's something to be said for sticking to the
portable character set for identifiers, such that the current locale
and or character set settings don't matter when compiling the source.

[David Brown]

I think if you are writing modern code, then it is pretty safe to assume
that UTF-8 is fine as a source character set. But you might have to
jump through some option flag hoops to make it work on some Windows tools.

There are two real disadvantages to using non-ASCII characters in
identifiers. One is that they can be hard to distinguish in some cases
- which of these is "complement" and which is "capital c"? "∁" "C"

The other is a matter of how you type the letters. If you speak Greek
and have a Greek keyboard layout, typing Greek letters for identifiers
is fine - if you have a Norwegian keyboard layout like mine, it's a
pain. I don't know of any layouts with ∀ and ∃ in them - if you use
them a lot, you'll want your own custom compose key combinations. But
even if the code author can get the symbols, people using or maintaining
the code might have trouble.


Still, we miss out on some fun opportunities when C and C++ only allow
letters, not symbols, in identifiers. It's entirely possible in C++ to
make your own pseudo-operators - identifiers that can be used prefix,
infix or postfix rather than as function calls. So you can make a
vector class and write "a crossproduct b" or "a dotproduct b", but you
are not allowed to write "#define × crossproduct" and "#define ·
dotproduct" to make it nicer in the source code.

[Alf P. Steinbach]

On 2023-03-27 7:59 PM, Jason Vas Dias wrote:
> Good day -
>
> I'd really like to be able to define functions with names like :
> ∀() (\U{FOR_ALL}), or ⭮() , or ⭯() , or :
> 8704 2200 (1 1) ∀ 'FOR ALL'
> 8705 2201 (1 1) ∁ 'COMPLEMENT'
> 8707 2203 (1 1) ∃ 'THERE EXISTS'
> 8708 2204 (1 1) ∄ 'THERE DOES NOT EXIST'
>
> Why can't I use these characters in identifiers ?

Unless changed in the most recent versions, g++ directly only allows
ASCII in identifiers, though it does support Unicode escapes (formally
universal character names) that denote non-ASCII characters.

The g++ behavior is -- or was -- essentially the rules of C, instead
of the rules of C++.

I'm being careful talking about versions because others have posted
commentary indicating that the g++ compiler they use, supports non-ASCII
characters in identifiers. I'm pretty sure they're wrong about that. But
there is the possibility of such support having been added recently.

> Would there be any support for submitting an RFC to the standards groups
> to allow implementations to have some sort of local UTF-8 character
> white-list policy ?

That discussion is now on mailing-lists. Originally it was in the now
defunct Usenet group comp.std.c++; then it was moved to Google groups;
then to mailing lists. Modulo possible changes (like, moved again) you
can find those lists at <url: http://isocpp.org>, somewhere.

> ie. I'd like to develop extensions for GCC and Clang that will allow them
> to load a UTF-8 character White-List file , then these characters would be
> allowed regardless of what the standards say about valid identifier characters.

Well the one I sorely miss is the up-arrow, ↑, to denote exponentiation.

But then, even if it was allowed, the usual technique of `%OP%` for
pseudo-operator yields precedence like % (remainder) which is not ideal.

Instead C++ should get support for exponentiation operator, possibly
`**` like Python.

> Next step is getting a complete dump of what GCC and Clang consider to
> be valid UTF-8 identifier characters, which is not as straightforward as it
> should be.

g++ is presumably dead easy; see above. :(

> I'd most appreciate any helpful advice / informative comments.

- Alf

[David Brown]

On 29/03/2023 13:42, Alf P. Steinbach wrote:
> On 2023-03-27 7:59 PM, Jason Vas Dias wrote:
>> Good day -
>>
>> I'd really like to be able to define functions with names like  :
>>     ∀()  (\U{FOR_ALL}), or   ⭮() , or ⭯() , or :
>>          8704    2200    (1 1)    ∀    'FOR ALL'
>>          8705    2201    (1 1)    ∁    'COMPLEMENT'
>>         8707    2203    (1 1)    ∃    'THERE EXISTS'
>>         8708    2204    (1 1)    ∄    'THERE DOES NOT EXIST'
>> Why can't I use these characters in identifiers ?
>
> Unless changed in the most recent versions, g++ directly only allows
> ASCII in identifiers, though it does support Unicode escapes (formally
> universal character names) that denote non-ASCII characters.
>

It changed with gcc 10, which is about 3 years old. (I don't know if
you consider that "recent" or not.)

> The g++ behavior is  --  or was -- essentially the rules of C, instead
> of the rules of C++.

C and C++ are, AFAIK, basically aligned on this - C has supported
"universal character names" since C99, and C++ had it in C++98.
Different compilers have had different levels of support, with clang
being relatively early in having full UTF-8 input support while gcc only
supported escape sequences (for C and C++) until gcc 10.

>
> I'm being careful talking about versions because others have posted
> commentary indicating that the g++ compiler they use, supports non-ASCII
> characters in identifiers. I'm pretty sure they're wrong about that. But
> there is the possibility of such support having been added recently.
>

Version 10 is the magic number.

>
>> Would there be any support for submitting an RFC to the standards groups
>> to allow implementations to have some sort of local UTF-8 character
>> white-list policy ?
>
> That discussion is now on mailing-lists. Originally it was in the now
> defunct Usenet group comp.std.c++; then it was moved to Google groups;
> then to mailing lists. Modulo possible changes (like, moved again) you
> can find those lists at <url: http://isocpp.org>, somewhere.
>
>
>> ie. I'd like to develop extensions for GCC and Clang that will allow them
>> to load a UTF-8 character White-List file , then these characters
>> would be
>> allowed regardless of what the standards say about valid identifier
>> characters.
>
> Well the one I sorely miss is the up-arrow, ↑, to denote exponentiation.
>
> But then, even if it was allowed, the usual technique of `%OP%` for
> pseudo-operator yields precedence like % (remainder) which is not ideal.
>
> Instead C++ should get support for exponentiation operator, possibly
> `**` like Python.

That's a feature many have called for, in C and C++, spanning decades.

>
>
>>   Next step is getting a complete dump of what GCC and Clang consider to
>>   be valid UTF-8 identifier characters, which is not as
>> straightforward as it
>>   should be.
>
> g++ is presumably dead easy; see above. :(
>

It's not particularly easy. GCC adds $ to the ASCII characters it
accepts as letters in identifiers (for most targets - there are some
targets for which $ is critically significant for the generated
assembly). Other than that, it follows the standard, with letters
defined in the XID_Start and XID_Continue classes in Unicode:

<https://www.unicode.org/reports/tr31/#Table_Lexical_Classes_for_Identifiers>

[Mut...@dastardlyhq.com]

On Wed, 29 Mar 2023 13:42:15 +0200
"Alf P. Steinbach" <alf.p.s...@gmail.com> wrote:
>Instead C++ should get support for exponentiation operator, possibly
>`**` like Python.

A pity richie/kernigan decided to use ^ for xor. I guess they wanted to keep
the bitwise operators as a single char but $ or @ would have been preferable.

[Mut...@dastardlyhq.com]

On Wed, 29 Mar 2023 14:23:25 +0200
David Brown <david...@hesbynett.no> wrote:
>On 29/03/2023 13:42, Alf P. Steinbach wrote:
>> Instead C++ should get support for exponentiation operator, possibly
>> `**` like Python.
>
>That's a feature many have called for, in C and C++, spanning decades.

Given how long it took to (officially) include 0b for binary literals I won't
be holding my breath. The amount of time that it could have personally saved
me in the past by not having to convert binary into hex and back would be
significant.

[Alf P. Steinbach]

On 2023-03-29 2:23 PM, David Brown wrote:
> On 29/03/2023 13:42, Alf P. Steinbach wrote:
>> On 2023-03-27 7:59 PM, Jason Vas Dias wrote:
>>> Good day -
>>>
>>> I'd really like to be able to define functions with names like  :
>>>     ∀()  (\U{FOR_ALL}), or   ⭮() , or ⭯() , or :
>>>          8704    2200    (1 1)    ∀    'FOR ALL'
>>>          8705    2201    (1 1)    ∁    'COMPLEMENT'
>>>         8707    2203    (1 1)    ∃    'THERE EXISTS'
>>>         8708    2204    (1 1)    ∄    'THERE DOES NOT EXIST'
>>> Why can't I use these characters in identifiers ?
>>
>> Unless changed in the most recent versions, g++ directly only allows
>> ASCII in identifiers, though it does support Unicode escapes (formally
>> universal character names) that denote non-ASCII characters.
>>
>
> It changed with gcc 10, which is about 3 years old.  (I don't know if
> you consider that "recent" or not.)

Oh. Thanks.

"
[C:\root\temp]
> g++ --version
g++ (GCC) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[C:\root\temp]
> bash
alf@Alf-Windows-PC:/mnt/c/root/temp$ g++ --version
g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
"

So how does that go for Ubuntu, like "sudo apt update something something"?

>> The g++ behavior is  --  or was -- essentially the rules of C, instead
>> of the rules of C++.
>
> C and C++ are, AFAIK, basically aligned on this - C has supported
> "universal character names" since C99, and C++ had it in C++98.
> Different compilers have had different levels of support, with clang
> being relatively early in having full UTF-8 input support while gcc only
> supported escape sequences (for C and C++) until gcc 10.

I meant the rules for identifiers.


[snip]

>
> It's not particularly easy.  GCC adds $ to the ASCII characters it
> accepts as letters in identifiers (for most targets - there are some
> targets for which $ is critically significant for the generated
> assembly).  Other than that, it follows the standard, with letters
> defined in the XID_Start and XID_Continue classes in Unicode:
>
> <https://www.unicode.org/reports/tr31/#Table_Lexical_Classes_for_Identifiers>

Most if not all extant compilers support `$`. Which I know because Herb
Sutter, the C++ standardization committee chair, once tried /using/ it
for some library stuff, and unlike my earlier efforts he got a lot of
people to try it and give feedback on it. The main problem wasn't
compilers but that some companies used `$` in their own preprocessing.

Probably the reason $ is not there in the C++ basic character set is the
destructively silly political argumentation that resulted in an
"international" version of ASCII with the not-used-ever-since-by-anybody
"international currency symbol" ¤ instead; <url:
https://en.wikipedia.org/wiki/Currency_sign_(typography)#History>.

The same kind of sensitivity-oriented people that now are removing scary
wording from Roald Dahl's novels and are on their way to ban "1984".

Mumble, mumble...

Anyway thanks!

I'll at least update the Windows MinGW version of g++, probably as easy
as downloading the Nuwen distro (maintained by STL over at Microsoft).

- Alf

[David Brown]

On 29/03/2023 19:03, Alf P. Steinbach wrote:
> On 2023-03-29 2:23 PM, David Brown wrote:
>> On 29/03/2023 13:42, Alf P. Steinbach wrote:
>>> On 2023-03-27 7:59 PM, Jason Vas Dias wrote:
>>>> Good day -
>>>>
>>>> I'd really like to be able to define functions with names like  :
>>>>     ∀()  (\U{FOR_ALL}), or   ⭮() , or ⭯() , or :
>>>>          8704    2200    (1 1)    ∀    'FOR ALL'
>>>>          8705    2201    (1 1)    ∁    'COMPLEMENT'
>>>>         8707    2203    (1 1)    ∃    'THERE EXISTS'
>>>>         8708    2204    (1 1)    ∄    'THERE DOES NOT EXIST'
>>>> Why can't I use these characters in identifiers ?
>>>
>>> Unless changed in the most recent versions, g++ directly only allows
>>> ASCII in identifiers, though it does support Unicode escapes
>>> (formally universal character names) that denote non-ASCII characters.
>>>
>>
>> It changed with gcc 10, which is about 3 years old.  (I don't know if
>> you consider that "recent" or not.)
>
> Oh. Thanks.
>

No problem. Some of us have an unhealthily detailed knowledge of these
things - it's nice when that knowledge helps someone!

You can always test on <https://godbolt.og>.

> "
> [C:\root\temp]
> > g++ --version
> g++ (GCC) 9.2.0
> Copyright (C) 2019 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> [C:\root\temp]
> > bash
> alf@Alf-Windows-PC:/mnt/c/root/temp$ g++ --version
> g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
> Copyright (C) 2019 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> "
>
> So how does that go for Ubuntu, like "sudo apt update something something"?
>

I believe gcc 10 is in the Ubuntu 20.04 packages:

apt update
apt install gcc-10

You'll still have standard gcc 9.x by default, and run gcc 10 as g++-10.

>
>>> The g++ behavior is  --  or was -- essentially the rules of C,
>>> instead of the rules of C++.
>>
>> C and C++ are, AFAIK, basically aligned on this - C has supported
>> "universal character names" since C99, and C++ had it in C++98.
>> Different compilers have had different levels of support, with clang
>> being relatively early in having full UTF-8 input support while gcc
>> only supported escape sequences (for C and C++) until gcc 10.
>
> I meant the rules for identifiers.
>

So did I - that's what I was talking about (not run-time character set
support).

>
> [snip]
>>
>> It's not particularly easy.  GCC adds $ to the ASCII characters it
>> accepts as letters in identifiers (for most targets - there are some
>> targets for which $ is critically significant for the generated
>> assembly).  Other than that, it follows the standard, with letters
>> defined in the XID_Start and XID_Continue classes in Unicode:
>>
>> <https://www.unicode.org/reports/tr31/#Table_Lexical_Classes_for_Identifiers>
>
> Most if not all extant compilers support `$`. Which I know because Herb
> Sutter, the C++ standardization committee chair, once tried /using/ it
> for some library stuff, and unlike my earlier efforts he got a lot of
> people to try it and give feedback on it. The main problem wasn't
> compilers but that some companies used `$` in their own preprocessing.
>

There are dozens of C++ compilers (and hundreds of C compilers) in use,
most of which neither you nor Sutter will have ever used, because they
are for embedded systems. Some support $, others do not. gcc supports
it, but some targets might not like it in their assembler. In
particular, many assemblers use $ to indicate hex literals, others use
it for register names. You might find that "a$" is fine, but "$0" is not.

Of course most code doesn't need to be fully portable, and $ in
identifiers will work fine for any toolchain most programmers are likely
to meet.

> Probably the reason $ is not there in the C++ basic character set is the
> destructively silly political argumentation that resulted in an
> "international" version of ASCII with the not-used-ever-since-by-anybody
> "international currency symbol" ¤ instead; <url:
> https://en.wikipedia.org/wiki/Currency_sign_(typography)#History>.
>

No, it is about compatibility with assemblers - when the C basic
character set was determined, $ was in heavy but inconsistent use in
many assemblers of the time. Allowing it as a letter in identifiers
would have made things a lot more complicated.

[Alf P. Steinbach]

On 2023-03-29 8:25 PM, David Brown wrote:
> On 29/03/2023 19:03, Alf P. Steinbach wrote:

> [snip]

>> Probably the reason $ is not there in the C++ basic character set is
>> the destructively silly political argumentation that resulted in an
>> "international" version of ASCII with the
>> not-used-ever-since-by-anybody "international currency symbol" ¤
>> instead; <url:
>> https://en.wikipedia.org/wiki/Currency_sign_(typography)#History>.
>
> No, it is about compatibility with assemblers - when the C basic
> character set was determined, $ was in heavy but inconsistent use in
> many assemblers of the time.  Allowing it as a letter in identifiers
> would have made things a lot more complicated.

Oh. I remember '@' for PDP-11 assembly and '$' for HP-3000 system
functions, but nothing about '$' for assembly. Learned something. :)

- Alf

[Sam]

Alf P. Steinbach writes:

> "
> [C:\root\temp]
> > g++ --version
> g++ (GCC) 9.2.0
> Copyright (C) 2019 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> [C:\root\temp]
> > bash
> alf@Alf-Windows-PC:/mnt/c/root/temp$ g++ --version
> g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
> Copyright (C) 2019 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> "
>
> So how does that go for Ubuntu, like "sudo apt update something something"?

I don't have an Ubuntu box, at this moment, but it should be "sudo apt
install g++-10". Ubuntu packages multiple versions of gcc, you would use
g++-10 to compile, etc…

[Scott Lurndal]

VMS heavily used $ in system call names at source level (e.g. C/Pascal SYS$QIOW)
and in MACRO-32 identifiers ($QIOW).

[Alf P. Steinbach]

Ah. Better. I should really have fixed the prompt and got an X-server
running in WSL (I know it's possible), and so on, but.


alf@Alf-Windows-PC:/mnt/c/root/temp$ (g++ --version; g++-10 --version) |
grep "++"
g++ (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
g++-10 (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0


- Alf

[jak]

Mut...@dastardlyhq.com ha scritto:

> A pity richie/kernigan decided to use ^ for xor. I guess they wanted to keep
> the bitwise operators as a single char but $ or @ would have been preferable.

For US keyboard users, this is, probably, a good idea.

[Mut...@dastardlyhq.com]

AFAIK those 2 characters are universal on PC keyboards regardless of
language.

[Paavo Helde]

At Soviet times, Russians did not want to see a dollar sign on their
keyboards, so it was replaced by a general currency sign ¤
("https://en.wikipedia.org/wiki/Currency_sign_(typography)"). It still
generated ASCII 36 though IIRC.

In standard Estonian keyboard layout, both @ and $ are accessible with
AltGr combinations, which are pretty inconvenient to type. Ditto for
brackets and braces []{}. That's why I'm myself using US keyboards only,
I need []{} much more than õäöü.

[David Brown]

The AltGr combinations for these symbols never bothered me on Norwegian
layout keyboards. When I moved from the UK to Norway many eons ago, it
took me a couple of weeks to get used to the changed layout, and I never
looked back. ~ is a little awkward, as it needs AltGr and it's a dead
key (thus needing a space after pressing it). But I don't see AltGr as
any harder to press than shift. I find the standard UK or US layout
restrictive and limited.

[Mut...@dastardlyhq.com]

Being able to access standard ascii characters used in C/C++ is restrictive
but requiring a load of AltGr nonsense isn't?

[james...@alumni.caltech.edu]

Well, AFAYK doesn't extend far enough. The variants compared in the table at
<https://en.m.wikipedia.org/wiki/ISO/IEC_646#Variant_comparison_chart>
were not created just for the fun of causing confusion. Each of those variants
was created because a fairly large group of people wanted to use keyboards
labeled with those variant characters, which could easily be used to type them,
along with monitors that would display them and printers that would print them.
Of the 60 variants compared in that chart, 21 have no '$' and 38 have no '@'.

[David Brown]

No - and I can't see how you interpreted my post so backwards.

I have no problem typing ASCII symbols such as $, @, #, {} and [] - I
just use the AltGr in some cases where others might use the shift key.
I do not find it makes any noticeable difference. Of course it takes
time to change habits and muscle memory - but once you are used to it,
one position is as good as another.

The restrictive nature of UK and US standard layouts comes into play
when you want to type something other than plain ASCII. I can write
I²C, µF, πr², 25°C, café, naïve, 2½, «Hello», and lots of other symbols
directly from the keyboard - no need for "character applets" or other
inconveniences when typing. (And obviously I can also type the
Norwegian letters å, ø and æ easily.) I like being able to write things
correctly - spelling peoples' names with the correct accents, and using
appropriate symbols instead of being limited to a character set
marginally beyond that of a typewriter.

[Mut...@dastardlyhq.com]

On Thu, 30 Mar 2023 08:48:42 -0700 (PDT)
"james...@alumni.caltech.edu" <james...@alumni.caltech.edu> wrote:
>On Thursday, March 30, 2023 at 4:25:10=E2=80=AFAM UTC-4, Mut...@dastardlyhq=
>..com wrote:
>> On Thu, 30 Mar 2023 04:00:33 +0200=20
>> jak <nos...@please.ty> wrote:=20
>> >Mut...@dastardlyhq.com ha scritto:=20
>> >> A pity richie/kernigan decided to use ^ for xor. I guess they wanted t=
>o keep=20
>> >> the bitwise operators as a single char but $ or @ would have been pref=
>erable.=20
>> >=20
>> >=20

>> >For US keyboard users, this is, probably, a good idea.

>> AFAIK those 2 characters are universal on PC keyboards regardless of=20
>> language.
>
>Well, AFAYK doesn't extend far enough. The variants compared in the table a=
>t
><https://en.m.wikipedia.org/wiki/ISO/IEC_646#Variant_comparison_chart>
>were not created just for the fun of causing confusion. Each of those varia=

>nts
>was created because a fairly large group of people wanted to use keyboards

>labeled with those variant characters, which could easily be used to type t=
>hem,
>along with monitors that would display them and printers that would print t=
>hem.
>Of the 60 variants compared in that chart, 21 have no '$' and 38 have no '@=
>'.

Any modern computer keyboard that doesn't allow immediate access to the basic
7 bit ascii character set is defective.

[Mut...@dastardlyhq.com]

On Thu, 30 Mar 2023 17:55:46 +0200
David Brown <david...@hesbynett.no> wrote:

>On 30/03/2023 17:19, Mut...@dastardlyhq.com wrote:
>> Being able to access standard ascii characters used in C/C++ is restrictive
>> but requiring a load of AltGr nonsense isn't?
>>
>
>No - and I can't see how you interpreted my post so backwards.
>
>I have no problem typing ASCII symbols such as $, @, #, {} and [] - I
>just use the AltGr in some cases where others might use the shift key.
>I do not find it makes any noticeable difference. Of course it takes
>time to change habits and muscle memory - but once you are used to it,
>one position is as good as another.
>
>The restrictive nature of UK and US standard layouts comes into play
>when you want to type something other than plain ASCII. I can write
>I²C, µF, πr², 25°C, café, naïve, 2½, «Hello», and lots of other
>symbols

Whatever those are they come out as gibberish in my terminal.

>directly from the keyboard - no need for "character applets" or other
>inconveniences when typing. (And obviously I can also type the
>Norwegian letters å, ø and æ easily.) I like being able to write things
>correctly - spelling peoples' names with the correct accents, and using
>appropriate symbols instead of being limited to a character set
>marginally beyond that of a typewriter.

I'm sure your norwegian keyboard would be really useful for typing french
or german.

7 bit ASCII is the default base for any PC (or Mac). A keyboard should make
all the ascii character easily accessable.

[David Brown]

On 30/03/2023 18:17, Mut...@dastardlyhq.com wrote:
> On Thu, 30 Mar 2023 17:55:46 +0200
> David Brown <david...@hesbynett.no> wrote:
>> On 30/03/2023 17:19, Mut...@dastardlyhq.com wrote:
>>> Being able to access standard ascii characters used in C/C++ is restrictive
>>> but requiring a load of AltGr nonsense isn't?
>>>
>>
>> No - and I can't see how you interpreted my post so backwards.
>>
>> I have no problem typing ASCII symbols such as $, @, #, {} and [] - I
>> just use the AltGr in some cases where others might use the shift key.
>> I do not find it makes any noticeable difference. Of course it takes
>> time to change habits and muscle memory - but once you are used to it,
>> one position is as good as another.
>>
>> The restrictive nature of UK and US standard layouts comes into play
>> when you want to type something other than plain ASCII. I can write
>> I²C, µF, πr², 25°C, café, naïve, 2½, «Hello», and lots of other
>> symbols
>
> Whatever those are they come out as gibberish in my terminal.

Are you unable to view UTF-8 ? What newsreader are you using?

>
>> directly from the keyboard - no need for "character applets" or other
>> inconveniences when typing. (And obviously I can also type the
>> Norwegian letters å, ø and æ easily.) I like being able to write things
>> correctly - spelling peoples' names with the correct accents, and using
>> appropriate symbols instead of being limited to a character set
>> marginally beyond that of a typewriter.
>
> I'm sure your norwegian keyboard would be really useful for typing french
> or german.

It would be fine for small texts - it is perfectly able to handle the
required accented letters such as ß, ç, ü, è, etc. I don't know if
French or German typists prefer a different layout or dedicated keys for
some of the accents or accented letters that they use more often. The
same goes for any other language written using Latin characters - I can
easily type the additional Iceland or Polish letters, but someone
writing in those languages might want dedicated keys (where I have keys
for the Norwegian letters) rather than AltGr + d, t, or l.

Once you get to different alphabets, for languages like Bulgarian or
Greek, it's a different matter - then you'd want a different keyboard
layout entirely.

>
> 7 bit ASCII is the default base for any PC (or Mac). A keyboard should make
> all the ascii character easily accessable.
>

My keyboard layout handles that fine. But it does more than that - I
live in the modern international world, not insular 1970's America, and
7-bit ASCII is not sufficient.

I believe it is quite practical to have UK or US layouts with dead keys
too, and get easy access to a range of additional characters while
keeping braces and brackets in the position you like.

[Paavo Helde]

30.03.2023 20:07 David Brown kirjutas:
>
> I believe it is quite practical to have UK or US layouts with dead keys
> too, and get easy access to a range of additional characters while
> keeping braces and brackets in the position you like.

Yes, that's the setup I'm using. Quote characters and tilde come via
dead keys this way, but I'm used to that.

[james...@alumni.caltech.edu]

On Thursday, March 30, 2023 at 12:15:43 PM UTC-4, Mut...@dastardlyhq.com wrote:
> On Thu, 30 Mar 2023 08:48:42 -0700 (PDT)
> "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> wrote:

...

> >Well, AFAYK doesn't extend far enough. The variants compared in the table a=
> >t
> ><https://en.m.wikipedia.org/wiki/ISO/IEC_646#Variant_comparison_chart>
> >were not created just for the fun of causing confusion. Each of those varia=
> >nts
> >was created because a fairly large group of people wanted to use keyboards
> >labeled with those variant characters, which could easily be used to type t=
> >hem,
> >along with monitors that would display them and printers that would print t=
> >hem.
> >Of the 60 variants compared in that chart, 21 have no '$' and 38 have no '@=
> >'.
>
> Any modern computer keyboard that doesn't allow immediate access to the basic
> 7 bit ascii character set is defective.

I'm sure that's true for you. However, those variants exist precisely because there are other people who would consider any keyboard which doesn't allow immediate access to their preferred variant to be defective.

[Scott Lurndal]

"james...@alumni.caltech.edu" <james...@alumni.caltech.edu> writes:
>On Thursday, March 30, 2023 at 12:15:43=E2=80=AFPM UTC-4, Mut...@dastardlyh=
>q.com wrote:
>> On Thu, 30 Mar 2023 08:48:42 -0700 (PDT)=20
>> "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> wrote:=20
>...
>> >Well, AFAYK doesn't extend far enough. The variants compared in the tabl=
>e a=3D=20
>> >t=20
>> ><https://en.m.wikipedia.org/wiki/ISO/IEC_646#Variant_comparison_chart>=
>=20
>> >were not created just for the fun of causing confusion. Each of those va=
>ria=3D
>> >nts=20
>> >was created because a fairly large group of people wanted to use keyboar=
>ds
>> >labeled with those variant characters, which could easily be used to typ=
>e t=3D=20
>> >hem,=20
>> >along with monitors that would display them and printers that would prin=
>t t=3D=20
>> >hem.=20
>> >Of the 60 variants compared in that chart, 21 have no '$' and 38 have no=
> '@=3D=20
>> >'.=20
>>=20
>> Any modern computer keyboard that doesn't allow immediate access to the b=
>asic=20

>> 7 bit ascii character set is defective.
>

>I'm sure that's true for you. However, those variants exist precisely becau=
>se there are other people who would consider any keyboard which doesn't all=

>ow immediate access to their preferred variant to be defective.

Muttley appears to be British, and many brits still believe the sun doesn't
set on the empire. That's no longer the case.

[Ben Bacarisse]

I think you are bundling more that is warranted into the phrase "UK and
US standard layouts". I have an entirely standard UK layout, but I can
type those characters with ease. The OS and it's input methods have
more to do with it than what I would call the "layout", but maybe I'm
missing something from what you mean by the term.

I don't think you will convince Muttley. There's a particular Internet
clan who see facilitating typing (or, God forbid, posting) non-ASCII
characters as the thin end of some subversive socialist wedge. First
they let you type an acute accent, but then they come for your guns!

--
Ben.

[Ben Bacarisse]

I am sad for my country's recent dive into xenophobic politics, but that
imperial attitude is not common among those young enough to know what an
emoji is! I thought Muttley was from the USA as ASCII-nationalism has,
historically, been more common in the US than in the UK.

--
Ben.

[Anssi Saari]

David Brown <david...@hesbynett.no> writes:

> I have no problem typing ASCII symbols such as $, @, #, {} and [] - I
> just use the AltGr in some cases where others might use the shift
> key. I do not find it makes any noticeable difference. Of course it
> takes time to change habits and muscle memory - but once you are used
> to it, one position is as good as another.

I don't agree. I want fast and easy access for the common punctuation
used in HDLs and software languages. Other less commonly used stuff can
go behind AltGr or just the right Alt on a US keyboard.

I've long thought the ¤ meant the asshole who designed the
Finnish/Swedish keyboard layout and have for a long time used the US
layout, no matter what's printed on the keys. Got familiar with xmodmap
in the 1990s when Sun workstations all came with US keyboards, even here
in Finland. xmodmap still does the job 30 years later. Other tools work
in other environments.

> The restrictive nature of UK and US standard layouts comes into play
> when you want to type something other than plain ASCII. I can write
> I²C, µF, πr², 25°C, café, naïve, 2½, «Hello», and lots of other
> symbols directly from the keyboard

Interesting. Maybe the Norwegian layout is more flexible than
Finnish/Swedish? I know I can get the common accents (´`¨~) from the
dead keys and § and ½ directly since they have a dedicated key but for
the rest... I guess I learned something.

[Mut...@dastardlyhq.com]

On Thu, 30 Mar 2023 17:53:38 GMT
sc...@slp53.sl.home (Scott Lurndal) wrote:

>"james...@alumni.caltech.edu" <james...@alumni.caltech.edu> writes:
>>> Any modern computer keyboard that doesn't allow immediate access to the b=
>>asic=20
>>> 7 bit ascii character set is defective.
>>
>>I'm sure that's true for you. However, those variants exist precisely becau=
>>se there are other people who would consider any keyboard which doesn't all=
>>ow immediate access to their preferred variant to be defective.
>
>Muttley appears to be British, and many brits still believe the sun doesn't
>set on the empire. That's no longer the case.

Before being a sarcastic jackass you might want to check whether the UK
keyboard is pure ascii too. It isn't. However, the standard ascii punctuation
characters aside from dollar are used all over the world and should be clearly
visible on any keyboard, not hidden.

[Mut...@dastardlyhq.com]

On Thu, 30 Mar 2023 20:21:52 +0100
Ben Bacarisse <ben.u...@bsb.me.uk> wrote:

>sc...@slp53.sl.home (Scott Lurndal) writes:
>>>I'm sure that's true for you. However, those variants exist precisely becau=
>>>se there are other people who would consider any keyboard which doesn't all=
>>>ow immediate access to their preferred variant to be defective.
>>
>> Muttley appears to be British, and many brits still believe the sun doesn't
>> set on the empire. That's no longer the case.
>
>I am sad for my country's recent dive into xenophobic politics, but that
>imperial attitude is not common among those young enough to know what an
>emoji is! I thought Muttley was from the USA as ASCII-nationalism has,
>historically, been more common in the US than in the UK.

Oh do fuck off you patronising arsewipe.

I was under the impression people who read this group were developers and
developers require the full set of ascii punctuation characters along with
anyone who does more online than write comments on tik-tok.

[Mut...@dastardlyhq.com]

On Thu, 30 Mar 2023 19:07:08 +0200

David Brown <david...@hesbynett.no> wrote:
>On 30/03/2023 18:17, Mut...@dastardlyhq.com wrote:
>> On Thu, 30 Mar 2023 17:55:46 +0200
>> David Brown <david...@hesbynett.no> wrote:
>>> On 30/03/2023 17:19, Mut...@dastardlyhq.com wrote:
>>>> Being able to access standard ascii characters used in C/C++ is restrictive
>
>>>> but requiring a load of AltGr nonsense isn't?
>>>>
>>>
>>> No - and I can't see how you interpreted my post so backwards.
>>>
>>> I have no problem typing ASCII symbols such as $, @, #, {} and [] - I
>>> just use the AltGr in some cases where others might use the shift key.
>>> I do not find it makes any noticeable difference. Of course it takes
>>> time to change habits and muscle memory - but once you are used to it,
>>> one position is as good as another.
>>>
>>> The restrictive nature of UK and US standard layouts comes into play
>>> when you want to type something other than plain ASCII. I can write
>>> I²C, µF, πr², 25°C, café, naïve, 2½, «Hello», and lots of other
>>> symbols
>>
>> Whatever those are they come out as gibberish in my terminal.
>
>Are you unable to view UTF-8 ? What newsreader are you using?

Its running in Mac Terminal.

[David Brown]

There are several aspects to keyboard layout. The most obvious one is
physical - when you buy an off-the-shelf keyboard in the UK, and one in
Norway, there are different symbols on the keys. When you look at your
"7" key, you'll see an "&" symbol accessible by "shift-7". I see "/"
above the 7, so "shift-7" on a Norwegian keyboard layout should give "/"
- I type "shift-6" for "&". My "7" key also has a "{" symbol to the
side - thus I use "AltGr-7" to get "{".

It is, of course, the OS and/or GUI and/or any configurable input
methods that determines how the low-level keycodes are interpreted. But
at a minimum, to be able to say you are using the standard UK or
Norwegian keyboard layouts, your system must support those physically
marked keys and symbols.

On the software side, keyboard layouts can support more. The standard
layouts on Windows support little more than the basics - for standard
English (not "international", "extended" or "deadkey" versions), you
have very little extra. With standard Norwegian layout, there are dead
keys for a few common diacriticals, usable on vowels (é è ë ê ẽ). It is
still very limited compared to Linux, but at least a step beyond the
standard UK or US English keyboard layout on Windows.

However, I have had very little use of standard English (UK or US)
keyboard layouts in Linux for a very long time - perhaps it supports
more than I thought. It is, of course, always possible to choose
international English varieties, enable AltGr, dead keys, a compose key,
and so on - but that's going beyond /standard/ layout. But are you
getting easy access to characters like Å ,ß, ¼ without having enabled
anything special?

> I don't think you will convince Muttley. There's a particular Internet
> clan who see facilitating typing (or, God forbid, posting) non-ASCII
> characters as the thin end of some subversive socialist wedge. First
> they let you type an acute accent, but then they come for your guns!
>

If anyone thinks they need non-ASCII letters, you should explain LOUDLY
and S L O W L Y why the Queen's English is good enough for them!

[Mut...@dastardlyhq.com]

I see the straw men are busy today.

Are you capable of comprehending the difference between

"need all ascii characters"

and

"not needing non ascii characters".

Given you claim to be a developer the simple boolean logic difference should
be evident.

[David Brown]

On 31/03/2023 10:18, Anssi Saari wrote:
> David Brown <david...@hesbynett.no> writes:
>
>> I have no problem typing ASCII symbols such as $, @, #, {} and [] - I
>> just use the AltGr in some cases where others might use the shift
>> key. I do not find it makes any noticeable difference. Of course it
>> takes time to change habits and muscle memory - but once you are used
>> to it, one position is as good as another.
>
> I don't agree. I want fast and easy access for the common punctuation
> used in HDLs and software languages. Other less commonly used stuff can
> go behind AltGr or just the right Alt on a US keyboard.

I don't know what you are disagreeing about - I /have/ fast and easy
access to the symbols used in common programming languages. (APL does
not count :-) ). I am at a loss as to why some people think it is hard
to type "AltGr-7" to get "{", and feel that "shift-[" is so much simpler
on /their/ layout. It is not as though I need to press "compose", "("
and "-" to get it.

>
> I've long thought the ¤ meant the asshole who designed the
> Finnish/Swedish keyboard layout and have for a long time used the US
> layout, no matter what's printed on the keys. Got familiar with xmodmap
> in the 1990s when Sun workstations all came with US keyboards, even here
> in Finland. xmodmap still does the job 30 years later. Other tools work
> in other environments.
>

There certainly was a time when multiple competing variants of ASCII
character sets were a problem. You'd try to print out your C code, and
the braces and brackets were replaced with Å or æ, or hash was replaced
by a pound sign. But that was a character set issue, not a keyboard
layout issue. I have never had an issue using Norwegian keyboards and
Norwegian keyboard layouts when typing C code. (But I only used Sun
workstations before I moved to Norway.)

>> The restrictive nature of UK and US standard layouts comes into play
>> when you want to type something other than plain ASCII. I can write
>> I²C, µF, πr², 25°C, café, naïve, 2½, «Hello», and lots of other
>> symbols directly from the keyboard
>
> Interesting. Maybe the Norwegian layout is more flexible than
> Finnish/Swedish? I know I can get the common accents (´`¨~) from the
> dead keys and § and ½ directly since they have a dedicated key but for
> the rest... I guess I learned something.

I should really have been more careful about the OS in question. I get
lots of extra symbols on the standard Norwegian layout on Linux - the
standard Norwegian layout on Windows has more possibilities than the
standard UK/US English layout on Windows, but not nearly as much as
Linux. I would assume the Finnish layout is very similar to the
Norwegian layout on both systems.

Or are you using a Finnish layout on Linux (or other X system) but don't
have ², π, Ω and other symbols accessible directly with AltGr ?

[David Brown]

On 30/03/2023 21:21, Ben Bacarisse wrote:

> I am sad for my country's recent dive into xenophobic politics, but that
> imperial attitude is not common among those young enough to know what an
> emoji is!

Unfortunately, it is the old xenophobes that make most of the policy.
The vote on Brexit should have had an upper age limit of perhaps 50 -
such important decisions about the future should be made by the people
who will live in that future, not those who are leaving.

(As a Scot, I am not xenophobic - merely anglophobic!)

[David Brown]

You mean like they are on my Norwegian keyboard? Clearly visible and
easy to type, as I have described?

I wonder if it is not just non-ASCII characters you have trouble reading.

[Mut...@dastardlyhq.com]

On Fri, 31 Mar 2023 13:05:59 +0200
David Brown <david...@hesbynett.no> wrote:
>On 30/03/2023 21:21, Ben Bacarisse wrote:
>
>> I am sad for my country's recent dive into xenophobic politics, but that
>> imperial attitude is not common among those young enough to know what an
>> emoji is!
>
>Unfortunately, it is the old xenophobes that make most of the policy.
>The vote on Brexit should have had an upper age limit of perhaps 50 -
>such important decisions about the future should be made by the people
>who will live in that future, not those who are leaving.

People aged 50 could live for another 50 years.

>
>(As a Scot, I am not xenophobic - merely anglophobic!)

Same thing. But now with Humza Useless as FM you can look forward to
Scotlandistan becoming a thing. Only SNP supporters could be thick enough
to believe a devout muslim would be more liberal than a christian.

[Mut...@dastardlyhq.com]

So what are you arguing about then? I'm simply saying all ascii characters
should be available on a keyboard.

>I wonder if it is not just non-ASCII characters you have trouble reading.

You wonder a lot and never seem to have any answers.

[David Brown]

Are you seriously posting blatant racism and religious prejudice here?

It is one thing to comment on the depressing but very real fact that
British politics has more xenophobic and insular in recent times. You
can agree or disagree with the politics - that's the freedom of a
democracy. But undisguised hate speech and bigotry - judging the SNP
leadership candidates purely on unjustified claims of stereotypical
group behaviours due to one aspect of their characters - that has no
place here or anywhere else.

My apologies to the rest of this group for my part in a thread which led
to such a post.

[Mut...@dastardlyhq.com]

On Fri, 31 Mar 2023 15:36:36 +0200

David Brown <david...@hesbynett.no> wrote:
>On 31/03/2023 13:27, Mut...@dastardlyhq.com wrote:
>> On Fri, 31 Mar 2023 13:05:59 +0200
>> David Brown <david...@hesbynett.no> wrote:
>>> On 30/03/2023 21:21, Ben Bacarisse wrote:
>>>
>>>> I am sad for my country's recent dive into xenophobic politics, but that
>>>> imperial attitude is not common among those young enough to know what an
>>>> emoji is!
>>>
>>> Unfortunately, it is the old xenophobes that make most of the policy.
>>> The vote on Brexit should have had an upper age limit of perhaps 50 -
>>> such important decisions about the future should be made by the people
>>> who will live in that future, not those who are leaving.
>>
>> People aged 50 could live for another 50 years.
>>
>>>
>>> (As a Scot, I am not xenophobic - merely anglophobic!) >
>> Same thing. But now with Humza Useless as FM you can look forward to
>> Scotlandistan becoming a thing. Only SNP supporters could be thick enough
>> to believe a devout muslim would be more liberal than a christian.
>>
>
>Are you seriously posting blatant racism and religious prejudice here?

My god, the irony meter just went off the scale!

>It is one thing to comment on the depressing but very real fact that
>British politics has more xenophobic and insular in recent times. You
>can agree or disagree with the politics - that's the freedom of a
>democracy. But undisguised hate speech and bigotry - judging the SNP
>leadership candidates purely on unjustified claims of stereotypical
>group behaviours due to one aspect of their characters - that has no
>place here or anywhere else.

Oh diddums, has ickle snowflake been triggered? Go to your safe space poppet
and hug the therapy teddy.

Fact: Strict Islam doesn't tolerate a number of liberal shibboleths.

Don't believe me? Visit saudi or iran and hold your boyfriends hand in the
street and see how long it is before you're carted away in a van.

>My apologies to the rest of this group for my part in a thread which led
>to such a post.

Yes, you should apologise for your clear xenophobia.

[Malcolm McLean]

On Friday, 31 March 2023 at 14:36:52 UTC+1, David Brown wrote:
>
> It is one thing to comment on the depressing but very real fact that
> British politics has more xenophobic and insular in recent times. You
> can agree or disagree with the politics - that's the freedom of a
> democracy. But undisguised hate speech and bigotry - judging the SNP
> leadership candidates purely on unjustified claims of stereotypical
> group behaviours due to one aspect of their characters - that has no
> place here or anywhere else.
>

Under the Labour government the British National Party (a far right
Britihs political party) had several council seats and two European
Parliament seats. Now they don't have a single one. It's not as simple
as you are saying. And it's hard to characterise the current governing
party as racist when it chose an Indian as Prime Minister.

[Scott Lurndal]

David was responding to Muttley's characterization of the current
Scottish Prime Minister, based soley on his religion.

[Keith Thompson]

Malcolm McLean <malcolm.ar...@gmail.com> writes:
> On Friday, 31 March 2023 at 14:36:52 UTC+1, David Brown wrote:
>> It is one thing to comment on the depressing but very real fact that
>> British politics

[...]

>>
> Under the Labour government the British National Party (a far right

[...]

Please stop.

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

[Mut...@dastardlyhq.com]

Not to bore anyone with parochial scottish politics, but practising christian
Kate Forbes - who was also the most qualified candidate - was ditched by the
woke mob when she revealed her admittedly 1950s views on certain topics.

The irony of course is that Yousaf being a devout practising muslim who has
even admitted consulting his imam on certain things and conveniently skipped a
key vote on gay marriage suddenly became the prefered candidate.

The real reason is he was the annointed successor to NS and the party machine
simply used any opportunity to torpedo the opposition. Which they did.

[Mut...@dastardlyhq.com]

On Fri, 31 Mar 2023 13:03:58 -0700
Keith Thompson <Keith.S.T...@gmail.com> wrote:
>Malcolm McLean <malcolm.ar...@gmail.com> writes:
>> On Friday, 31 March 2023 at 14:36:52 UTC+1, David Brown wrote:
>>> It is one thing to comment on the depressing but very real fact that
>>> British politics
>[...]
>>>
>> Under the Labour government the British National Party (a far right
>[...]
>
>Please stop.

Yet its ok to discuss the xenophobic Scottish National Party?

[Mut...@dastardlyhq.com]

On Fri, 31 Mar 2023 20:03:05 GMT
sc...@slp53.sl.home (Scott Lurndal) wrote:

Btw, its First Minister, not Prime Minister. The FM and the scottish parliament
only has devolved power in certain civil areas such as health, education,
transport etc. They're not nearly as powerful or important as they like to
pretend, they're more like regional council.

[Anssi Saari]

David Brown <david...@hesbynett.no> writes:

> I don't know what you are disagreeing about - I /have/ fast and easy
> access to the symbols used in common programming languages.

And that's where we disagree. AltGr with anything isn't fast or easy in
my opinion, it's good for those symbols used once a month or
thereabouts. I get you don't get it, moving on.

> I should really have been more careful about the OS in question. I
> get lots of extra symbols on the standard Norwegian layout on Linux -
> the standard Norwegian layout on Windows has more possibilities than
> the standard UK/US English layout on Windows, but not nearly as much
> as Linux. I would assume the Finnish layout is very similar to the
> Norwegian layout on both systems.

Seems reasonable. I guess I haven't really used other than US layout in
Linux. I can't avoid Windows+Orifice even though my real HW work is all
in Linux so the Windows Finnish layout is all I know.

What provides the keyboard layouts in Linux, is it X with xkbset or do
the various desktop environments provide their own?

[James Kuyper]

On 4/3/23 03:11, Anssi Saari wrote:
> David Brown <david...@hesbynett.no> writes:
>
>> I don't know what you are disagreeing about - I /have/ fast and easy
>> access to the symbols used in common programming languages.
>
> And that's where we disagree. AltGr with anything isn't fast or easy in
> my opinion, it's good for those symbols used once a month or
> thereabouts. I get you don't get it, moving on.

According to the Wikipedia article on the AltGr key, it is usually
mapped to a key that's in the same place as the right 'Alt' on many US
keyboards, including my own.
That article indicates that the common keyboard setup in Norway uses
AltGr to display the following characters that I can type directly on my
US keyboard: @${[]}~'. Of those 9 characters, there's only two that I
can type without using the shift key. I just tried typing those
characters using my right 'Alt' key as if I had a Norwegian keyboard
set up. Except for 'AltGr'+'0' => '}', they weren't any harder to type
than the shift sequences I needed for those same characters on a US
keyboard.
What makes you feel that the 'AltGr' key is so difficult to use that it
should be used only once a month? Do you avoid using shifts, too?

[Scott Lurndal]

FWIW, one of the reasons I dislike camelcase is the need to use the
shift key too frequently, and I type fast enough that the shift
often sticks to the next keystroke which necessitates correction.

[Paavo Helde]

AltGr is on the same side of the keyboard as the most needed []{}\, so
two keys 4 rows apart need to be pressed at the same time with the same
hand. Can be done, but a bit cumbersome. Maybe it's just a habit thing.

Maybe it's different with Norwegian layout, they mentioned dead keys. On
Estonian keyboard AltGr is a modifier which is not a dead key, so needs
to be pressed simultaneously.

[Jason Vas Dias]

Many thanks to all who responded !

A most interesting discussion.

Yes, it seems there WOULD be considerable support for some sort of
-unicode-whitelist=$file
option for GCC and Clang, and good reasons for providing one.

I will develop 2 patches over the next week, and send them to the
GCC and Clang teams to do this, and I'll try writing a request
for allowing non-standards compliant unicode identifier characters
in C + C++.

Those who responded to this post might be interested in :

https://bugzilla.redhat.com/show_bug.cgi?id=2182144

where I discuss some of the issues & difficulties with GCC & Clang's
handling of this issue with some Clang & GCC experts.

I've attached a small C header defining macros that allow you to do things
like:

'
#include "M.h"

U32_t
dash_unicode_name = 𝕌8N(,,,,F,E,6,A);
const char*
dash=🙶(𝕌8N﹩(,,,,F,E,6,A));
inline U32_t
dash_unicode()
{ return 𝕌𝕍﹩𝒷(&dash);
}

#define ﹣() _ǝ(𝕌8N﹩(,,,,F,E,6,A))

#define L a,1,b,2,c

const char*
dashed=_Ɐ_(﹩🙶,﹣(),L)"3";
'

which, through 'gcc -I. -E', produces:
'
# 2 "t2.c" 2

U32_t
dash_unicode_name = 0x0000FF6A;
const char*
dash="\U0000FE6A";
inline U32_t
dash_unicode()
{ return (ntohl(( (((U32_t)((byte)((*((B4_t)(&dash)))[3])))<<24)| (((U32_t)((byte)((*((B4_t)(&dash)))[2])))<<16)| (((U32_t)((byte)((*((B4_t)(&dash)))[1])))<<8)| ((U32_t)((byte)((*((B4_t)(&dash)))[0])))))>>8U);
}

const char*
dashed="a""\U0000FE6A""1""\U0000FE6A""b""\U0000FE6A""2""\U0000FE6A""c""\U0000FE6A""3";
'
Please check out M.h and the test files at :

https://drive.google.com/file/d/1--9qYAbHHK0cXqLhg0JMOg9vaQMZM5uc/view?usp=sharing,
https://drive.google.com/file/d/1D3e8a27q0leRqkwppLyVY3m_bsSdib5K/view?usp=sharing,
https://drive.google.com/file/d/1jc1G-VupYxn7MDTjrJyyot6GXguP0_-j/view?usp=sharing

( you can't actually attach files to newsgroup messages, can you?)

Best Regards,
Jason

> Good day -
>
> I'd really like to be able to define functions with names like :
> ∀() (\U{FOR_ALL}), or ⭮() , or ⭯() , or :
> 8704 2200 (1 1) ∀ 'FOR ALL'
> 8705 2201 (1 1) ∁ 'COMPLEMENT'
> 8707 2203 (1 1) ∃ 'THERE EXISTS'
> 8708 2204 (1 1) ∄ 'THERE DOES NOT EXIST'
>
> Why can't I use these characters in identifiers ?
>
> Would there be any support for submitting an RFC to the standards groups
> to allow implementations to have some sort of local UTF-8 character
> white-list policy ?
>
> ie. I'd like to develop extensions for GCC and Clang that will allow them
> to load a UTF-8 character White-List file , then these characters would be
> allowed regardless of what the standards say about valid identifier characters.
>
> Next step is getting a complete dump of what GCC and Clang consider to
> be valid UTF-8 identifier characters, which is not as straightforward as it
> should be.
>
> I'd most appreciate any helpful advice / informative comments.
>
> Thanks & Best Regards,
> Jason
>
>
> Richard Damon Ric...@damon-family.org via googlegroups.com
> 27 Mar 2023, 20:03 (8 days ago)
> to
>
>
> My understanding is that C++ basically just took the set of characters
> for identifiers from the recommendation of the Unicode Standard for
> "Identifiers" (XID_Start, XID_Continue). All the characters you
> mentioned are defined (I beleive) as operators.
>
> My one thought is that the Standard Committee wants to reserve the
> operators from being identifies in case at some point a method is
> defined to add new operators.
>
> My guess is that GCC and Clang just implement the set defined by the
> standard, which means going to the UNICODE standard that is applicable
> for that compiler and looking at its definition of those classes. I
> wouldn't be surprised if the build process just has as an input, the
> Unicode class definition file, and a program that parses it to build the
> needed code for the various things that need that information.
>
> Of course, there is nothing to prevent an implementation from accepting
> additional characters (possibly with a warning or an option) beyond the
> defined set.
>
>
> sc...@slp53.sl.home via googlegroups.com
> 27 Mar 2023, 20:08 (8 days ago)
> to
>
>
> Actually, there's something to be said for sticking to the
> portable character set for identifiers, such that the current locale
> and or character set settings don't matter when compiling the source.
>
>
>
> David Brown david...@hesbynett.no via googlegroups.com
> 28 Mar 2023, 08:10 (7 days ago)
> to
>
>
> I think if you are writing modern code, then it is pretty safe to assume
> that UTF-8 is fine as a source character set. But you might have to
> jump through some option flag hoops to make it work on some Windows tools.
>
> There are two real disadvantages to using non-ASCII characters in
> identifiers. One is that they can be hard to distinguish in some cases
> - which of these is "complement" and which is "capital c"? "∁" "C"
>
> The other is a matter of how you type the letters. If you speak Greek
> and have a Greek keyboard layout, typing Greek letters for identifiers
> is fine - if you have a Norwegian keyboard layout like mine, it's a
> pain. I don't know of any layouts with ∀ and ∃ in them - if you use
> them a lot, you'll want your own custom compose key combinations. But
> even if the code author can get the symbols, people using or maintaining
> the code might have trouble.
>
>
> Still, we miss out on some fun opportunities when C and C++ only allow
> letters, not symbols, in identifiers. It's entirely possible in C++ to
> make your own pseudo-operators - identifiers that can be used prefix,
> infix or postfix rather than as function calls. So you can make a
> vector class and write "a crossproduct b" or "a dotproduct b", but you
> are not allowed to write "#define × crossproduct" and "#define ·
> dotproduct" to make it nicer in the source code.
>
>
>
>
> Alf P. Steinbach alf.p.s...@gmail.com via googlegroups.com
> 29 Mar 2023, 12:42 (6 days ago)
> to
>
> On 2023-03-27 7:59 PM, Jason Vas Dias wrote:
> > Good day -
> >
> > I'd really like to be able to define functions with names like :
> > ∀() (\U{FOR_ALL}), or ⭮() , or ⭯() , or :
> > 8704 2200 (1 1) ∀ 'FOR ALL'
> > 8705 2201 (1 1) ∁ 'COMPLEMENT'
> > 8707 2203 (1 1) ∃ 'THERE EXISTS'
> > 8708 2204 (1 1) ∄ 'THERE DOES NOT EXIST'
> >
> > Why can't I use these characters in identifiers ?
>
> Unless changed in the most recent versions, g++ directly only allows
> ASCII in identifiers, though it does support Unicode escapes (formally
> universal character names) that denote non-ASCII characters.
>
> The g++ behavior is -- or was -- essentially the rules of C, instead
> of the rules of C++.
>
> I'm being careful talking about versions because others have posted
> commentary indicating that the g++ compiler they use, supports non-ASCII
> characters in identifiers. I'm pretty sure they're wrong about that. But
> there is the possibility of such support having been added recently.
>
>
> > Would there be any support for submitting an RFC to the standards groups
> > to allow implementations to have some sort of local UTF-8 character
> > white-list policy ?
>
> That discussion is now on mailing-lists. Originally it was in the now
> defunct Usenet group comp.std.c++; then it was moved to Google groups;
> then to mailing lists. Modulo possible changes (like, moved again) you
> can find those lists at <url: http://isocpp.org>, somewhere.
>
>
> > ie. I'd like to develop extensions for GCC and Clang that will allow them
> > to load a UTF-8 character White-List file , then these characters would be
> > allowed regardless of what the standards say about valid identifier characters.
>
> Well the one I sorely miss is the up-arrow, ↑, to denote exponentiation.
>
> But then, even if it was allowed, the usual technique of `%OP%` for
> pseudo-operator yields precedence like % (remainder) which is not ideal.
>
> Instead C++ should get support for exponentiation operator, possibly
> `**` like Python.
>
>
> > Next step is getting a complete dump of what GCC and Clang consider to
> > be valid UTF-8 identifier characters, which is not as straightforward as it
> > should be.
>
> g++ is presumably dead easy; see above. :(
> - Alf
>
>
> David Brown david...@hesbynett.no via googlegroups.com
> 29 Mar 2023, 13:24 (6 days ago)
> to
>
> On 29/03/2023 13:42, Alf P. Steinbach wrote:
> > On 2023-03-27 7:59 PM, Jason Vas Dias wrote:
> >> Good day -
> >>
> >> I'd really like to be able to define functions with names like :
> >> ∀() (\U{FOR_ALL}), or ⭮() , or ⭯() , or :
> >> 8704 2200 (1 1) ∀ 'FOR ALL'
> >> 8705 2201 (1 1) ∁ 'COMPLEMENT'
> >> 8707 2203 (1 1) ∃ 'THERE EXISTS'
> >> 8708 2204 (1 1) ∄ 'THERE DOES NOT EXIST'
> >> Why can't I use these characters in identifiers ?
> >
> > Unless changed in the most recent versions, g++ directly only allows
> > ASCII in identifiers, though it does support Unicode escapes (formally
> > universal character names) that denote non-ASCII characters.
> >
>
> It changed with gcc 10, which is about 3 years old. (I don't know if
> you consider that "recent" or not.)
>
> > The g++ behavior is -- or was -- essentially the rules of C, instead
> > of the rules of C++.
>
> C and C++ are, AFAIK, basically aligned on this - C has supported
> "universal character names" since C99, and C++ had it in C++98.
> Different compilers have had different levels of support, with clang
> being relatively early in having full UTF-8 input support while gcc only
> supported escape sequences (for C and C++) until gcc 10.
>
> >
> > I'm being careful talking about versions because others have posted
> > commentary indicating that the g++ compiler they use, supports non-ASCII
> > characters in identifiers. I'm pretty sure they're wrong about that. But
> > there is the possibility of such support having been added recently.
> >
>
> Version 10 is the magic number.
>
> >
> >> Would there be any support for submitting an RFC to the standards groups
> >> to allow implementations to have some sort of local UTF-8 character
> >> white-list policy ?
> >
> > That discussion is now on mailing-lists. Originally it was in the now
> > defunct Usenet group comp.std.c++; then it was moved to Google groups;
> > then to mailing lists. Modulo possible changes (like, moved again) you
> > can find those lists at <url: http://isocpp.org>, somewhere.
> >
> >
> >> ie. I'd like to develop extensions for GCC and Clang that will allow them
> >> to load a UTF-8 character White-List file , then these characters
> >> would be
> >> allowed regardless of what the standards say about valid identifier
> >> characters.
> >
> > Well the one I sorely miss is the up-arrow, ↑, to denote exponentiation.
> >
> > But then, even if it was allowed, the usual technique of `%OP%` for
> > pseudo-operator yields precedence like % (remainder) which is not ideal.
> >
> > Instead C++ should get support for exponentiation operator, possibly
> > `**` like Python.
>
> That's a feature many have called for, in C and C++, spanning decades.
>
> >
> >
> >> Next step is getting a complete dump of what GCC and Clang consider to
> >> be valid UTF-8 identifier characters, which is not as
> >> straightforward as it
> >> should be.
> >
> > g++ is presumably dead easy; see above. :(
> >
>
> It's not particularly easy. GCC adds $ to the ASCII characters it
> accepts as letters in identifiers (for most targets - there are some
> targets for which $ is critically significant for the generated
> assembly). Other than that, it follows the standard, with letters
> defined in the XID_Start and XID_Continue classes in Unicode:
>
> <https://www.unicode.org/reports/tr31/#Table_Lexical_Classes_for_Identifiers>
>
>
> Mut...@dastardlyhq.com via googlegroups.com
> 29 Mar 2023, 14:39 (6 days ago)
> to
>
> On Wed, 29 Mar 2023 13:42:15 +0200
> "Alf P. Steinbach" <alf.p.s...@gmail.com> wrote:
> >Instead C++ should get support for exponentiation operator, possibly
> >`**` like Python.
>
> A pity richie/kernigan decided to use ^ for xor. I guess they wanted to keep
> the bitwise operators as a single char but $ or @ would have been preferable.
>
>
>
>
> Mut...@dastardlyhq.com via googlegroups.com
> 29 Mar 2023, 14:41 (6 days ago)
> to
>
> On Wed, 29 Mar 2023 14:23:25 +0200
> David Brown <david...@hesbynett.no> wrote:
> >On 29/03/2023 13:42, Alf P. Steinbach wrote:
> >> Instead C++ should get support for exponentiation operator, possibly
> >> `**` like Python.
> >
> >That's a feature many have called for, in C and C++, spanning decades.
>
> Given how long it took to (officially) include 0b for binary literals I won't
> be holding my breath. The amount of time that it could have personally saved
> me in the past by not having to convert binary into hex and back would be
> significant.
>
>
>
> Alf P. Steinbach alf.p.s...@gmail.com via googlegroups.com
> 29 Mar 2023, 18:03 (6 days ago)
> to
>
> On 2023-03-29 2:23 PM, David Brown wrote:
> > On 29/03/2023 13:42, Alf P. Steinbach wrote:
> >> On 2023-03-27 7:59 PM, Jason Vas Dias wrote:
> >>> Good day -
> >>>
> >>> I'd really like to be able to define functions with names like :
> >>> ∀() (\U{FOR_ALL}), or ⭮() , or ⭯() , or :
> >>> 8704 2200 (1 1) ∀ 'FOR ALL'
> >>> 8705 2201 (1 1) ∁ 'COMPLEMENT'
> >>> 8707 2203 (1 1) ∃ 'THERE EXISTS'
> >>> 8708 2204 (1 1) ∄ 'THERE DOES NOT EXIST'
> >>> Why can't I use these characters in identifiers ?
> >>
> >> Unless changed in the most recent versions, g++ directly only allows
> >> ASCII in identifiers, though it does support Unicode escapes (formally
> >> universal character names) that denote non-ASCII characters.
> >>
> >
> > It changed with gcc 10, which is about 3 years old. (I don't know if
> > you consider that "recent" or not.)
>
> Oh. Thanks.
>
> "
> [C:\root\temp]
> > g++ --version
> g++ (GCC) 9.2.0
> Copyright (C) 2019 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> [C:\root\temp]
> > bash
> alf@Alf-Windows-PC:/mnt/c/root/temp$ g++ --version
> g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
> Copyright (C) 2019 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> "
>
> So how does that go for Ubuntu, like "sudo apt update something something"?
>
>
> >> The g++ behavior is -- or was -- essentially the rules of C, instead
> >> of the rules of C++.
> >
> > C and C++ are, AFAIK, basically aligned on this - C has supported
> > "universal character names" since C99, and C++ had it in C++98.
> > Different compilers have had different levels of support, with clang
> > being relatively early in having full UTF-8 input support while gcc only
> > supported escape sequences (for C and C++) until gcc 10.
>
> I meant the rules for identifiers.
>
>
> [snip]
> >
> > It's not particularly easy. GCC adds $ to the ASCII characters it
> > accepts as letters in identifiers (for most targets - there are some
> > targets for which $ is critically significant for the generated
> > assembly). Other than that, it follows the standard, with letters
> > defined in the XID_Start and XID_Continue classes in Unicode:
> >
> > <https://www.unicode.org/reports/tr31/#Table_Lexical_Classes_for_Identifiers>
>
> Most if not all extant compilers support `$`. Which I know because Herb
> Sutter, the C++ standardization committee chair, once tried /using/ it
> for some library stuff, and unlike my earlier efforts he got a lot of
> people to try it and give feedback on it. The main problem wasn't
> compilers but that some companies used `$` in their own preprocessing.
>
> Probably the reason $ is not there in the C++ basic character set is the
> destructively silly political argumentation that resulted in an
> "international" version of ASCII with the not-used-ever-since-by-anybody
> "international currency symbol" ¤ instead; <url:
> https://en.wikipedia.org/wiki/Currency_sign_(typography)#History>.
>
> The same kind of sensitivity-oriented people that now are removing scary
> wording from Roald Dahl's novels and are on their way to ban "1984".
>
> Mumble, mumble...
>
> Anyway thanks!
>
> I'll at least update the Windows MinGW version of g++, probably as easy
> as downloading the Nuwen distro (maintained by STL over at Microsoft).
>
> - Alf
>
>
> David Brown david...@hesbynett.no via googlegroups.com
> 29 Mar 2023, 19:25 (6 days ago)
> to
>
> On 29/03/2023 19:03, Alf P. Steinbach wrote:
> > On 2023-03-29 2:23 PM, David Brown wrote:
> >> On 29/03/2023 13:42, Alf P. Steinbach wrote:
> >>> On 2023-03-27 7:59 PM, Jason Vas Dias wrote:
> >>>> Good day -
> >>>>
> >>>> I'd really like to be able to define functions with names like :
> >>>> ∀() (\U{FOR_ALL}), or ⭮() , or ⭯() , or :
> >>>> 8704 2200 (1 1) ∀ 'FOR ALL'
> >>>> 8705 2201 (1 1) ∁ 'COMPLEMENT'
> >>>> 8707 2203 (1 1) ∃ 'THERE EXISTS'
> >>>> 8708 2204 (1 1) ∄ 'THERE DOES NOT EXIST'
> >>>> Why can't I use these characters in identifiers ?
> >>>
> >>> Unless changed in the most recent versions, g++ directly only allows
> >>> ASCII in identifiers, though it does support Unicode escapes
> >>> (formally universal character names) that denote non-ASCII characters.
> >>>
> >>
> >> It changed with gcc 10, which is about 3 years old. (I don't know if
> >> you consider that "recent" or not.)
> >
> > Oh. Thanks.
> >
>
> No problem. Some of us have an unhealthily detailed knowledge of these
> things - it's nice when that knowledge helps someone!
>
> You can always test on <https://godbolt.og>.
>
> > "
> > [C:\root\temp]
> > > g++ --version
> > g++ (GCC) 9.2.0
> > Copyright (C) 2019 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions. There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> >
> > [C:\root\temp]
> > > bash
> > alf@Alf-Windows-PC:/mnt/c/root/temp$ g++ --version
> > g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
> > Copyright (C) 2019 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions. There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> > "
> >
> > So how does that go for Ubuntu, like "sudo apt update something something"?
> >
>
> I believe gcc 10 is in the Ubuntu 20.04 packages:
>
> apt update
> apt install gcc-10
>
> You'll still have standard gcc 9.x by default, and run gcc 10 as g++-10.
>
> >
> >>> The g++ behavior is -- or was -- essentially the rules of C,
> >>> instead of the rules of C++.
> >>
> >> C and C++ are, AFAIK, basically aligned on this - C has supported
> >> "universal character names" since C99, and C++ had it in C++98.
> >> Different compilers have had different levels of support, with clang
> >> being relatively early in having full UTF-8 input support while gcc
> >> only supported escape sequences (for C and C++) until gcc 10.
> >
> > I meant the rules for identifiers.
> >
>
> So did I - that's what I was talking about (not run-time character set
> support).
>
> >
> > [snip]
> >>
> >> It's not particularly easy. GCC adds $ to the ASCII characters it
> >> accepts as letters in identifiers (for most targets - there are some
> >> targets for which $ is critically significant for the generated
> >> assembly). Other than that, it follows the standard, with letters
> >> defined in the XID_Start and XID_Continue classes in Unicode:
> >>
> >> <https://www.unicode.org/reports/tr31/#Table_Lexical_Classes_for_Identifiers>
> >
> > Most if not all extant compilers support `$`. Which I know because Herb
> > Sutter, the C++ standardization committee chair, once tried /using/ it
> > for some library stuff, and unlike my earlier efforts he got a lot of
> > people to try it and give feedback on it. The main problem wasn't
> > compilers but that some companies used `$` in their own preprocessing.
> >
>
> There are dozens of C++ compilers (and hundreds of C compilers) in use,
> most of which neither you nor Sutter will have ever used, because they
> are for embedded systems. Some support $, others do not. gcc supports
> it, but some targets might not like it in their assembler. In
> particular, many assemblers use $ to indicate hex literals, others use
> it for register names. You might find that "a$" is fine, but "$0" is not.
>
> Of course most code doesn't need to be fully portable, and $ in
> identifiers will work fine for any toolchain most programmers are likely
> to meet.
>
> > Probably the reason $ is not there in the C++ basic character set is the
> > destructively silly political argumentation that resulted in an
> > "international" version of ASCII with the not-used-ever-since-by-anybody
> > "international currency symbol" ¤ instead; <url:
> > https://en.wikipedia.org/wiki/Currency_sign_(typography)#History>.
> >
>
> No, it is about compatibility with assemblers - when the C basic
> character set was determined, $ was in heavy but inconsistent use in
> many assemblers of the time. Allowing it as a letter in identifiers
> would have made things a lot more complicated.
>
>
> Alf P. Steinbach alf.p.s...@gmail.com via googlegroups.com
> 29 Mar 2023, 20:07 (6 days ago)
> to
>
> This message looks like spam. When you opened this message, Gmail checked it again for spam signals.
> Move to spamLooks safe
> On 2023-03-29 8:25 PM, David Brown wrote:
> > On 29/03/2023 19:03, Alf P. Steinbach wrote:
> > [snip]
> >> Probably the reason $ is not there in the C++ basic character set is
> >> the destructively silly political argumentation that resulted in an
> >> "international" version of ASCII with the
> >> not-used-ever-since-by-anybody "international currency symbol" ¤
> >> instead; <url:
> >> https://en.wikipedia.org/wiki/Currency_sign_(typography)#History>.
> >
> > No, it is about compatibility with assemblers - when the C basic
> > character set was determined, $ was in heavy but inconsistent use in
> > many assemblers of the time. Allowing it as a letter in identifiers
> > would have made things a lot more complicated.
>
> Oh. I remember '@' for PDP-11 assembly and '$' for HP-3000 system
> functions, but nothing about '$' for assembly. Learned something. :)
>
> - Alf
>
>
> Sam s...@email-scan.com via googlegroups.com
> 29 Mar 2023, 20:22 (6 days ago)
> to
>
> Alf P. Steinbach writes:
>
> > "
> > [C:\root\temp]
> > > g++ --version
> > g++ (GCC) 9.2.0
> > Copyright (C) 2019 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions. There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> >
> > [C:\root\temp]
> > > bash
> > alf@Alf-Windows-PC:/mnt/c/root/temp$ g++ --version
> > g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
> > Copyright (C) 2019 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions. There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> > "
> >
> > So how does that go for Ubuntu, like "sudo apt update something something"?
>
> I don't have an Ubuntu box, at this moment, but it should be "sudo apt
> install g++-10". Ubuntu packages multiple versions of gcc, you would use
> g++-10 to compile, etc…
>
>
>
> sc...@slp53.sl.home via googlegroups.com
> 29 Mar 2023, 20:32 (6 days ago)
> to
>
> "Alf P. Steinbach" <alf.p.s...@gmail.com> writes:
> >On 2023-03-29 8:25 PM, David Brown wrote:
> >> On 29/03/2023 19:03, Alf P. Steinbach wrote:
> >> [snip]
> >>> Probably the reason $ is not there in the C++ basic character set is
> >>> the destructively silly political argumentation that resulted in an
> >>> "international" version of ASCII with the
> >>> not-used-ever-since-by-anybody "international currency symbol" ¤
> >>> instead; <url:
> >>> https://en.wikipedia.org/wiki/Currency_sign_(typography)#History>.
> >>
> >> No, it is about compatibility with assemblers - when the C basic
> >> character set was determined, $ was in heavy but inconsistent use in
> >> many assemblers of the time. Allowing it as a letter in identifiers
> >> would have made things a lot more complicated.
> >
> >Oh. I remember '@' for PDP-11 assembly and '$' for HP-3000 system
> >functions, but nothing about '$' for assembly. Learned something. :)
>
> VMS heavily used $ in system call names at source level (e.g. C/Pascal SYS$QIOW)
> and in MACRO-32 identifiers ($QIOW).
>
>
> Alf P. Steinbach alf.p.s...@gmail.com via googlegroups.com
> 29 Mar 2023, 22:16 (6 days ago)
> to
>
>
> Ah. Better. I should really have fixed the prompt and got an X-server
> running in WSL (I know it's possible), and so on, but.
>
>
> alf@Alf-Windows-PC:/mnt/c/root/temp$ (g++ --version; g++-10 --version) |
> grep "++"
> g++ (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
> g++-10 (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0
>
>
> - Alf
>
>
> jak nos...@please.ty via googlegroups.com
> 30 Mar 2023, 03:00 (5 days ago)
> to
>
> Mut...@dastardlyhq.com ha scritto:
> > A pity richie/kernigan decided to use ^ for xor. I guess they wanted to keep
> > the bitwise operators as a single char but $ or @ would have been preferable.
>
> For US keyboard users, this is, probably, a good idea.
>
>
> Mut...@dastardlyhq.com via googlegroups.com
> 30 Mar 2023, 09:25 (5 days ago)
> to
>
>
> AFAIK those 2 characters are universal on PC keyboards regardless of
> language.
>
>
>
> Paavo Helde ees...@osa.pri.ee via googlegroups.com
> 30 Mar 2023, 13:21 (5 days ago)
> to
>
>
> At Soviet times, Russians did not want to see a dollar sign on their
> keyboards, so it was replaced by a general currency sign ¤
> ("https://en.wikipedia.org/wiki/Currency_sign_(typography)"). It still
> generated ASCII 36 though IIRC.
>
> In standard Estonian keyboard layout, both @ and $ are accessible with
> AltGr combinations, which are pretty inconvenient to type. Ditto for
> brackets and braces []{}. That's why I'm myself using US keyboards only,
> I need []{} much more than õäöü.
>
>
>
>
>
> David Brown david...@hesbynett.no via googlegroups.com
> 30 Mar 2023, 15:34 (5 days ago)
> to

>
>
> The AltGr combinations for these symbols never bothered me on Norwegian
> layout keyboards. When I moved from the UK to Norway many eons ago, it
> took me a couple of weeks to get used to the changed layout, and I never
> looked back. ~ is a little awkward, as it needs AltGr and it's a dead
> key (thus needing a space after pressing it). But I don't see AltGr as
> any harder to press than shift. I find the standard UK or US layout
> restrictive and limited.
>
>
>
>

> Mut...@dastardlyhq.com via googlegroups.com
> 30 Mar 2023, 16:20 (5 days ago)
> to

>
>
> Being able to access standard ascii characters used in C/C++ is restrictive
> but requiring a load of AltGr nonsense isn't?
>
>
>
>

> 'james...@alumni.caltech.edu' via comp.lang.c++ <comp.l...@googlegroups.com>
> 30 Mar 2023, 16:48 (5 days ago)
> to
>
> On Thursday, March 30, 2023 at 4:25:10 AM UTC-4, Mut...@dastardlyhq.com wrote:
> > On Thu, 30 Mar 2023 04:00:33 +0200
> > jak <nos...@please.ty> wrote:
> > >Mut...@dastardlyhq.com ha scritto:
> > >> A pity richie/kernigan decided to use ^ for xor. I guess they wanted to keep
> > >> the bitwise operators as a single char but $ or @ would have been preferable.
> > >
> > >
> > >For US keyboard users, this is, probably, a good idea.
> > AFAIK those 2 characters are universal on PC keyboards regardless of
> > language.
>
> Well, AFAYK doesn't extend far enough. The variants compared in the table at
> <https://en.m.wikipedia.org/wiki/ISO/IEC_646#Variant_comparison_chart>
> were not created just for the fun of causing confusion. Each of those variants
> was created because a fairly large group of people wanted to use keyboards
> labeled with those variant characters, which could easily be used to type them,
> along with monitors that would display them and printers that would print them.
> Of the 60 variants compared in that chart, 21 have no '$' and 38 have no '@'.
>
>
> David Brown david...@hesbynett.no via googlegroups.com
> 30 Mar 2023, 16:56 (5 days ago)
> to

>
>
> No - and I can't see how you interpreted my post so backwards.
>

> I have no problem typing ASCII symbols such as $, @, #, {} and [] - I
> just use the AltGr in some cases where others might use the shift key.
> I do not find it makes any noticeable difference. Of course it takes
> time to change habits and muscle memory - but once you are used to it,
> one position is as good as another.
>

> The restrictive nature of UK and US standard layouts comes into play
> when you want to type something other than plain ASCII. I can write
> I²C, µF, πr², 25°C, café, naïve, 2½, «Hello», and lots of other symbols

> directly from the keyboard - no need for "character applets" or other
> inconveniences when typing. (And obviously I can also type the
> Norwegian letters å, ø and æ easily.) I like being able to write things
> correctly - spelling peoples' names with the correct accents, and using
> appropriate symbols instead of being limited to a character set
> marginally beyond that of a typewriter.
>
>
>
>
>
>
>

> Mut...@dastardlyhq.com via googlegroups.com
> 30 Mar 2023, 17:15 (5 days ago)
> to
>
> On Thu, 30 Mar 2023 08:48:42 -0700 (PDT)
> "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> wrote:
> >On Thursday, March 30, 2023 at 4:25:10=E2=80=AFAM UTC-4, Mut...@dastardlyhq=
> >..com wrote:
> >> On Thu, 30 Mar 2023 04:00:33 +0200=20
> >> jak <nos...@please.ty> wrote:=20
> >> >Mut...@dastardlyhq.com ha scritto:=20
> >> >> A pity richie/kernigan decided to use ^ for xor. I guess they wanted t=
> >o keep=20
> >> >> the bitwise operators as a single char but $ or @ would have been pref=
> >erable.=20
> >> >=20
> >> >=20
> >> >For US keyboard users, this is, probably, a good idea.
> >> AFAIK those 2 characters are universal on PC keyboards regardless of=20
> >> language.
> >
> >Well, AFAYK doesn't extend far enough. The variants compared in the table a=
> >t
> ><https://en.m.wikipedia.org/wiki/ISO/IEC_646#Variant_comparison_chart>
> >were not created just for the fun of causing confusion. Each of those varia=
> >nts
> >was created because a fairly large group of people wanted to use keyboards
> >labeled with those variant characters, which could easily be used to type t=
> >hem,
> >along with monitors that would display them and printers that would print t=
> >hem.
> >Of the 60 variants compared in that chart, 21 have no '$' and 38 have no '@=
> >'.
>
> Any modern computer keyboard that doesn't allow immediate access to the basic

> 7 bit ascii character set is defective.
>
>
>

> Mut...@dastardlyhq.com via googlegroups.com
> 30 Mar 2023, 17:17 (5 days ago)
> to
>
> On Thu, 30 Mar 2023 17:55:46 +0200
> David Brown <david...@hesbynett.no> wrote:

> >On 30/03/2023 17:19, Mut...@dastardlyhq.com wrote:
> >> Being able to access standard ascii characters used in C/C++ is restrictive
> >> but requiring a load of AltGr nonsense isn't?
> >>
> >
> >No - and I can't see how you interpreted my post so backwards.
> >

> >I have no problem typing ASCII symbols such as $, @, #, {} and [] - I
> >just use the AltGr in some cases where others might use the shift key.
> >I do not find it makes any noticeable difference. Of course it takes
> >time to change habits and muscle memory - but once you are used to it,
> >one position is as good as another.
> >

> >The restrictive nature of UK and US standard layouts comes into play
> >when you want to type something other than plain ASCII. I can write
> >I²C, µF, πr², 25°C, café, naïve, 2½, «Hello», and lots of other
> >symbols
>

> Whatever those are they come out as gibberish in my terminal.
>

> >directly from the keyboard - no need for "character applets" or other
> >inconveniences when typing. (And obviously I can also type the
> >Norwegian letters å, ø and æ easily.) I like being able to write things
> >correctly - spelling peoples' names with the correct accents, and using
> >appropriate symbols instead of being limited to a character set
> >marginally beyond that of a typewriter.
>

> I'm sure your norwegian keyboard would be really useful for typing french
> or german.
>
> 7 bit ASCII is the default base for any PC (or Mac). A keyboard should make
> all the ascii character easily accessable.
>
>
>
> David Brown david...@hesbynett.no via googlegroups.com
> 30 Mar 2023, 18:07 (5 days ago)
> to
>
> On 30/03/2023 18:17, Mut...@dastardlyhq.com wrote:
> > On Thu, 30 Mar 2023 17:55:46 +0200
> > David Brown <david...@hesbynett.no> wrote:

> >> On 30/03/2023 17:19, Mut...@dastardlyhq.com wrote:
> >>> Being able to access standard ascii characters used in C/C++ is restrictive
> >>> but requiring a load of AltGr nonsense isn't?
> >>>
> >>
> >> No - and I can't see how you interpreted my post so backwards.
> >>

> >> I have no problem typing ASCII symbols such as $, @, #, {} and [] - I
> >> just use the AltGr in some cases where others might use the shift key.
> >> I do not find it makes any noticeable difference. Of course it takes
> >> time to change habits and muscle memory - but once you are used to it,
> >> one position is as good as another.
> >>

> >> The restrictive nature of UK and US standard layouts comes into play
> >> when you want to type something other than plain ASCII. I can write
> >> I²C, µF, πr², 25°C, café, naïve, 2½, «Hello», and lots of other
> >> symbols
> >

> > Whatever those are they come out as gibberish in my terminal.
>
> Are you unable to view UTF-8 ? What newsreader are you using?
>
> >

> >> directly from the keyboard - no need for "character applets" or other
> >> inconveniences when typing. (And obviously I can also type the
> >> Norwegian letters å, ø and æ easily.) I like being able to write things
> >> correctly - spelling peoples' names with the correct accents, and using
> >> appropriate symbols instead of being limited to a character set
> >> marginally beyond that of a typewriter.
> >

> > I'm sure your norwegian keyboard would be really useful for typing french
> > or german.
>
> It would be fine for small texts - it is perfectly able to handle the
> required accented letters such as ß, ç, ü, è, etc. I don't know if
> French or German typists prefer a different layout or dedicated keys for
> some of the accents or accented letters that they use more often. The
> same goes for any other language written using Latin characters - I can
> easily type the additional Iceland or Polish letters, but someone
> writing in those languages might want dedicated keys (where I have keys
> for the Norwegian letters) rather than AltGr + d, t, or l.
>
> Once you get to different alphabets, for languages like Bulgarian or
> Greek, it's a different matter - then you'd want a different keyboard
> layout entirely.
>
> >
> > 7 bit ASCII is the default base for any PC (or Mac). A keyboard should make
> > all the ascii character easily accessable.
> >
>
> My keyboard layout handles that fine. But it does more than that - I
> live in the modern international world, not insular 1970's America, and
> 7-bit ASCII is not sufficient.
>
> I believe it is quite practical to have UK or US layouts with dead keys
> too, and get easy access to a range of additional characters while
> keeping braces and brackets in the position you like.
>
>
>
>
> Paavo Helde ees...@osa.pri.ee via googlegroups.com
> 30 Mar 2023, 18:24 (5 days ago)
> to
>
> 30.03.2023 20:07 David Brown kirjutas:
> >
> > I believe it is quite practical to have UK or US layouts with dead keys
> > too, and get easy access to a range of additional characters while
> > keeping braces and brackets in the position you like.
>
> Yes, that's the setup I'm using. Quote characters and tilde come via
> dead keys this way, but I'm used to that.
>
>
>
> 'james...@alumni.caltech.edu' via comp.lang.c++ <comp.l...@googlegroups.com>
> 30 Mar 2023, 18:40 (5 days ago)
> to
>
> On Thursday, March 30, 2023 at 12:15:43 PM UTC-4, Mut...@dastardlyhq.com wrote:

> > On Thu, 30 Mar 2023 08:48:42 -0700 (PDT)
> > "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> wrote:
> ...

> > >Well, AFAYK doesn't extend far enough. The variants compared in the table a=
> > >t
> > ><https://en.m.wikipedia.org/wiki/ISO/IEC_646#Variant_comparison_chart>
> > >were not created just for the fun of causing confusion. Each of those varia=
> > >nts
> > >was created because a fairly large group of people wanted to use keyboards
> > >labeled with those variant characters, which could easily be used to type t=
> > >hem,
> > >along with monitors that would display them and printers that would print t=
> > >hem.
> > >Of the 60 variants compared in that chart, 21 have no '$' and 38 have no '@=
> > >'.
> >
> > Any modern computer keyboard that doesn't allow immediate access to the basic

> > 7 bit ascii character set is defective.
>

> I'm sure that's true for you. However, those variants exist precisely because there are other people who would consider any keyboard which doesn't allow immediate access to their preferred variant to be defective.
>
>
> sc...@slp53.sl.home via googlegroups.com
> 30 Mar 2023, 18:53 (5 days ago)
> to

>
> "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> writes:
> >On Thursday, March 30, 2023 at 12:15:43=E2=80=AFPM UTC-4, Mut...@dastardlyh=

> >q.com wrote:
> >> On Thu, 30 Mar 2023 08:48:42 -0700 (PDT)=20
> >> "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> wrote:=20
> >...
> >> >Well, AFAYK doesn't extend far enough. The variants compared in the tabl=
> >e a=3D=20
> >> >t=20
> >> ><https://en.m.wikipedia.org/wiki/ISO/IEC_646#Variant_comparison_chart>=
> >=20
> >> >were not created just for the fun of causing confusion. Each of those va=
> >ria=3D
> >> >nts=20
> >> >was created because a fairly large group of people wanted to use keyboar=
> >ds
> >> >labeled with those variant characters, which could easily be used to typ=
> >e t=3D=20
> >> >hem,=20
> >> >along with monitors that would display them and printers that would prin=
> >t t=3D=20
> >> >hem.=20
> >> >Of the 60 variants compared in that chart, 21 have no '$' and 38 have no=
> > '@=3D=20
> >> >'.=20
> >>=20

> >> Any modern computer keyboard that doesn't allow immediate access to the b=
> >asic=20
> >> 7 bit ascii character set is defective.
> >
> >I'm sure that's true for you. However, those variants exist precisely becau=
> >se there are other people who would consider any keyboard which doesn't all=
> >ow immediate access to their preferred variant to be defective.
>
> Muttley appears to be British, and many brits still believe the sun doesn't
> set on the empire. That's no longer the case.
>
>

> Ben Bacarisse ben.u...@bsb.me.uk via googlegroups.com
> 30 Mar 2023, 20:14 (5 days ago)
> to

>
>
> I think you are bundling more that is warranted into the phrase "UK and
> US standard layouts". I have an entirely standard UK layout, but I can
> type those characters with ease. The OS and it's input methods have
> more to do with it than what I would call the "layout", but maybe I'm
> missing something from what you mean by the term.
>

> I don't think you will convince Muttley. There's a particular Internet
> clan who see facilitating typing (or, God forbid, posting) non-ASCII
> characters as the thin end of some subversive socialist wedge. First
> they let you type an acute accent, but then they come for your guns!
>

> --
> Ben.
>
> Ben Bacarisse ben.u...@bsb.me.uk via googlegroups.com
> 30 Mar 2023, 20:22 (5 days ago)
> to

>
>
> I am sad for my country's recent dive into xenophobic politics, but that
> imperial attitude is not common among those young enough to know what an

> emoji is! I thought Muttley was from the USA as ASCII-nationalism has,
> historically, been more common in the US than in the UK.
>

> --
> Ben.
>
> Anssi Saari a...@sci.fi via googlegroups.com
> 31 Mar 2023, 09:18 (4 days ago)
> to

>
> David Brown <david...@hesbynett.no> writes:
>
> > I have no problem typing ASCII symbols such as $, @, #, {} and [] - I
> > just use the AltGr in some cases where others might use the shift
> > key. I do not find it makes any noticeable difference. Of course it
> > takes time to change habits and muscle memory - but once you are used
> > to it, one position is as good as another.
>
> I don't agree. I want fast and easy access for the common punctuation
> used in HDLs and software languages. Other less commonly used stuff can
> go behind AltGr or just the right Alt on a US keyboard.
>

> I've long thought the ¤ meant the asshole who designed the
> Finnish/Swedish keyboard layout and have for a long time used the US
> layout, no matter what's printed on the keys. Got familiar with xmodmap
> in the 1990s when Sun workstations all came with US keyboards, even here
> in Finland. xmodmap still does the job 30 years later. Other tools work
> in other environments.
>

> > The restrictive nature of UK and US standard layouts comes into play
> > when you want to type something other than plain ASCII. I can write
> > I²C, µF, πr², 25°C, café, naïve, 2½, «Hello», and lots of other
> > symbols directly from the keyboard
>
> Interesting. Maybe the Norwegian layout is more flexible than
> Finnish/Swedish? I know I can get the common accents (´`¨~) from the
> dead keys and § and ½ directly since they have a dedicated key but for
> the rest... I guess I learned something.
>
>

> Mut...@dastardlyhq.com via googlegroups.com
> 31 Mar 2023, 10:16 (4 days ago)
> to

>
> On Thu, 30 Mar 2023 17:53:38 GMT
> sc...@slp53.sl.home (Scott Lurndal) wrote:
> >"james...@alumni.caltech.edu" <james...@alumni.caltech.edu> writes:
> >>> Any modern computer keyboard that doesn't allow immediate access to the b=
> >>asic=20
> >>> 7 bit ascii character set is defective.
> >>
> >>I'm sure that's true for you. However, those variants exist precisely becau=
> >>se there are other people who would consider any keyboard which doesn't all=
> >>ow immediate access to their preferred variant to be defective.
> >
> >Muttley appears to be British, and many brits still believe the sun doesn't
> >set on the empire. That's no longer the case.
>
> Before being a sarcastic jackass you might want to check whether the UK
> keyboard is pure ascii too. It isn't. However, the standard ascii punctuation
> characters aside from dollar are used all over the world and should be clearly
> visible on any keyboard, not hidden.
>
>
>

> Mut...@dastardlyhq.com via googlegroups.com
> 31 Mar 2023, 10:18 (4 days ago)
> to

>
> On Thu, 30 Mar 2023 20:21:52 +0100
> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
> >sc...@slp53.sl.home (Scott Lurndal) writes:

> >>>I'm sure that's true for you. However, those variants exist precisely becau=
> >>>se there are other people who would consider any keyboard which doesn't all=
> >>>ow immediate access to their preferred variant to be defective.
> >>
> >> Muttley appears to be British, and many brits still believe the sun doesn't
> >> set on the empire. That's no longer the case.
> >

> >I am sad for my country's recent dive into xenophobic politics, but that
> >imperial attitude is not common among those young enough to know what an

> >emoji is! I thought Muttley was from the USA as ASCII-nationalism has,
> >historically, been more common in the US than in the UK.
>
> Oh do fuck off you patronising arsewipe.
>
> I was under the impression people who read this group were developers and
> developers require the full set of ascii punctuation characters along with
> anyone who does more online than write comments on tik-tok.
>
>
>

> Mut...@dastardlyhq.com via googlegroups.com
> 31 Mar 2023, 10:18 (4 days ago)
> to
>
> On Thu, 30 Mar 2023 19:07:08 +0200
> David Brown <david...@hesbynett.no> wrote:
> >On 30/03/2023 18:17, Mut...@dastardlyhq.com wrote:
> >> On Thu, 30 Mar 2023 17:55:46 +0200
> >> David Brown <david...@hesbynett.no> wrote:

> >>> On 30/03/2023 17:19, Mut...@dastardlyhq.com wrote:
> >>>> Being able to access standard ascii characters used in C/C++ is restrictive
> >
> >>>> but requiring a load of AltGr nonsense isn't?
> >>>>
> >>>
> >>> No - and I can't see how you interpreted my post so backwards.
> >>>

> >>> I have no problem typing ASCII symbols such as $, @, #, {} and [] - I
> >>> just use the AltGr in some cases where others might use the shift key.
> >>> I do not find it makes any noticeable difference. Of course it takes
> >>> time to change habits and muscle memory - but once you are used to it,
> >>> one position is as good as another.
> >>>

> >>> The restrictive nature of UK and US standard layouts comes into play
> >>> when you want to type something other than plain ASCII. I can write
> >>> I²C, µF, πr², 25°C, café, naïve, 2½, «Hello», and lots of other
> >>> symbols
> >>

> >> Whatever those are they come out as gibberish in my terminal.
> >
> >Are you unable to view UTF-8 ? What newsreader are you using?
>
> Its running in Mac Terminal.
>
>
>

> David Brown david...@hesbynett.no via googlegroups.com
> 31 Mar 2023, 11:41 (4 days ago)
> to

> > I don't think you will convince Muttley. There's a particular Internet
> > clan who see facilitating typing (or, God forbid, posting) non-ASCII
> > characters as the thin end of some subversive socialist wedge. First
> > they let you type an acute accent, but then they come for your guns!
> >
>
> If anyone thinks they need non-ASCII letters, you should explain LOUDLY
> and S L O W L Y why the Queen's English is good enough for them!
>
>
>
>

> Mut...@dastardlyhq.com via googlegroups.com
> 31 Mar 2023, 11:58 (4 days ago)
> to

>
>
> I see the straw men are busy today.
>
> Are you capable of comprehending the difference between
>
> "need all ascii characters"
>
> and
>
> "not needing non ascii characters".
>
> Given you claim to be a developer the simple boolean logic difference should
> be evident.
>
>
>

> David Brown david...@hesbynett.no via googlegroups.com
> 31 Mar 2023, 12:00 (4 days ago)
> to

>
> On 31/03/2023 10:18, Anssi Saari wrote:
> > David Brown <david...@hesbynett.no> writes:
> >

> >> I have no problem typing ASCII symbols such as $, @, #, {} and [] - I
> >> just use the AltGr in some cases where others might use the shift
> >> key. I do not find it makes any noticeable difference. Of course it
> >> takes time to change habits and muscle memory - but once you are used
> >> to it, one position is as good as another.
> >
> > I don't agree. I want fast and easy access for the common punctuation
> > used in HDLs and software languages. Other less commonly used stuff can
> > go behind AltGr or just the right Alt on a US keyboard.
>

> I don't know what you are disagreeing about - I /have/ fast and easy

> I should really have been more careful about the OS in question. I get
> lots of extra symbols on the standard Norwegian layout on Linux - the
> standard Norwegian layout on Windows has more possibilities than the
> standard UK/US English layout on Windows, but not nearly as much as
> Linux. I would assume the Finnish layout is very similar to the
> Norwegian layout on both systems.
>

> Or are you using a Finnish layout on Linux (or other X system) but don't
> have ², π, Ω and other symbols accessible directly with AltGr ?
>
>
>
>
>

> David Brown david...@hesbynett.no via googlegroups.com
> 31 Mar 2023, 12:06 (4 days ago)
> to

>
> On 30/03/2023 21:21, Ben Bacarisse wrote:
>
> > I am sad for my country's recent dive into xenophobic politics, but that
> > imperial attitude is not common among those young enough to know what an
> > emoji is!
>
> Unfortunately, it is the old xenophobes that make most of the policy.
> The vote on Brexit should have had an upper age limit of perhaps 50 -
> such important decisions about the future should be made by the people
> who will live in that future, not those who are leaving.
>

> (As a Scot, I am not xenophobic - merely anglophobic!)
>
>
>

> David Brown david...@hesbynett.no via googlegroups.com
> 31 Mar 2023, 12:08 (4 days ago)
> to

>
>
> You mean like they are on my Norwegian keyboard? Clearly visible and
> easy to type, as I have described?
>

> I wonder if it is not just non-ASCII characters you have trouble reading.
>
>
>

> Mut...@dastardlyhq.com via googlegroups.com
> 31 Mar 2023, 12:27 (4 days ago)
> to

>
> On Fri, 31 Mar 2023 13:05:59 +0200
> David Brown <david...@hesbynett.no> wrote:
> >On 30/03/2023 21:21, Ben Bacarisse wrote:
> >
> >> I am sad for my country's recent dive into xenophobic politics, but that
> >> imperial attitude is not common among those young enough to know what an
> >> emoji is!
> >
> >Unfortunately, it is the old xenophobes that make most of the policy.
> >The vote on Brexit should have had an upper age limit of perhaps 50 -
> >such important decisions about the future should be made by the people
> >who will live in that future, not those who are leaving.
>
> People aged 50 could live for another 50 years.
>
> >
> >(As a Scot, I am not xenophobic - merely anglophobic!)
>
> Same thing. But now with Humza Useless as FM you can look forward to
> Scotlandistan becoming a thing. Only SNP supporters could be thick enough
> to believe a devout muslim would be more liberal than a christian.
>
>
>

> Mut...@dastardlyhq.com via googlegroups.com
> 31 Mar 2023, 12:28 (4 days ago)
> to

>
> On Fri, 31 Mar 2023 13:08:00 +0200
> David Brown <david...@hesbynett.no> wrote:
> >On 31/03/2023 11:16, Mut...@dastardlyhq.com wrote:

> >> On Thu, 30 Mar 2023 17:53:38 GMT
> >> sc...@slp53.sl.home (Scott Lurndal) wrote:
> >>> "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> writes:
> >>>>> Any modern computer keyboard that doesn't allow immediate access to the b=
> >
> >>>> asic=20
> >>>>> 7 bit ascii character set is defective.
> >>>>
> >>>> I'm sure that's true for you. However, those variants exist precisely
> >becau=
> >>>> se there are other people who would consider any keyboard which doesn't
> >all=
> >>>> ow immediate access to their preferred variant to be defective.
> >>>
> >>> Muttley appears to be British, and many brits still believe the sun doesn't
> >>> set on the empire. That's no longer the case.
> >>
> >> Before being a sarcastic jackass you might want to check whether the UK
> >> keyboard is pure ascii too. It isn't. However, the standard ascii punctuation
> >
> >> characters aside from dollar are used all over the world and should be
> >clearly
> >> visible on any keyboard, not hidden.
> >>
> >
> >You mean like they are on my Norwegian keyboard? Clearly visible and
> >easy to type, as I have described?
>
> So what are you arguing about then? I'm simply saying all ascii characters
> should be available on a keyboard.
>
> >I wonder if it is not just non-ASCII characters you have trouble reading.
>
> You wonder a lot and never seem to have any answers.
>
>
>

> David Brown david...@hesbynett.no via googlegroups.com
> 31 Mar 2023, 14:36 (4 days ago)
> to

>
>
> Are you seriously posting blatant racism and religious prejudice here?
>

> It is one thing to comment on the depressing but very real fact that
> British politics has more xenophobic and insular in recent times. You
> can agree or disagree with the politics - that's the freedom of a
> democracy. But undisguised hate speech and bigotry - judging the SNP
> leadership candidates purely on unjustified claims of stereotypical
> group behaviours due to one aspect of their characters - that has no
> place here or anywhere else.
>

> My apologies to the rest of this group for my part in a thread which led
> to such a post.
>
>
>

> Mut...@dastardlyhq.com via googlegroups.com
> 31 Mar 2023, 16:00 (4 days ago)
> to

>
> On Fri, 31 Mar 2023 15:36:36 +0200
> David Brown <david...@hesbynett.no> wrote:
> >On 31/03/2023 13:27, Mut...@dastardlyhq.com wrote:
> >> On Fri, 31 Mar 2023 13:05:59 +0200
> >> David Brown <david...@hesbynett.no> wrote:
> >>> On 30/03/2023 21:21, Ben Bacarisse wrote:
> >>>
> >>>> I am sad for my country's recent dive into xenophobic politics, but that
> >>>> imperial attitude is not common among those young enough to know what an
> >>>> emoji is!
> >>>
> >>> Unfortunately, it is the old xenophobes that make most of the policy.
> >>> The vote on Brexit should have had an upper age limit of perhaps 50 -
> >>> such important decisions about the future should be made by the people
> >>> who will live in that future, not those who are leaving.
> >>
> >> People aged 50 could live for another 50 years.
> >>
> >>>
> >>> (As a Scot, I am not xenophobic - merely anglophobic!) >
> >> Same thing. But now with Humza Useless as FM you can look forward to
> >> Scotlandistan becoming a thing. Only SNP supporters could be thick enough
> >> to believe a devout muslim would be more liberal than a christian.
> >>
> >
> >Are you seriously posting blatant racism and religious prejudice here?
>
> My god, the irony meter just went off the scale!
>

> >It is one thing to comment on the depressing but very real fact that
> >British politics has more xenophobic and insular in recent times. You
> >can agree or disagree with the politics - that's the freedom of a
> >democracy. But undisguised hate speech and bigotry - judging the SNP
> >leadership candidates purely on unjustified claims of stereotypical
> >group behaviours due to one aspect of their characters - that has no
> >place here or anywhere else.
>

> Oh diddums, has ickle snowflake been triggered? Go to your safe space poppet
> and hug the therapy teddy.
>
> Fact: Strict Islam doesn't tolerate a number of liberal shibboleths.
>
> Don't believe me? Visit saudi or iran and hold your boyfriends hand in the
> street and see how long it is before you're carted away in a van.
>
> >My apologies to the rest of this group for my part in a thread which led
> >to such a post.
>
> Yes, you should apologise for your clear xenophobia.
>
>
>

> Malcolm McLean malcolm.ar...@gmail.com via googlegroups.com
> 31 Mar 2023, 20:38 (4 days ago)
> to

>
> On Friday, 31 March 2023 at 14:36:52 UTC+1, David Brown wrote:
> >
> > It is one thing to comment on the depressing but very real fact that
> > British politics has more xenophobic and insular in recent times. You
> > can agree or disagree with the politics - that's the freedom of a
> > democracy. But undisguised hate speech and bigotry - judging the SNP
> > leadership candidates purely on unjustified claims of stereotypical
> > group behaviours due to one aspect of their characters - that has no
> > place here or anywhere else.
> >
> Under the Labour government the British National Party (a far right
> Britihs political party) had several council seats and two European
> Parliament seats. Now they don't have a single one. It's not as simple
> as you are saying. And it's hard to characterise the current governing
> party as racist when it chose an Indian as Prime Minister.
>
>

> sc...@slp53.sl.home via googlegroups.com
> 31 Mar 2023, 21:03 (4 days ago)
> to

>
>
> David was responding to Muttley's characterization of the current
> Scottish Prime Minister, based soley on his religion.
>
>

> Keith Thompson Keith.S.T...@gmail.com via googlegroups.com
> 31 Mar 2023, 21:04 (4 days ago)
> to

>
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> > On Friday, 31 March 2023 at 14:36:52 UTC+1, David Brown wrote:
> >> It is one thing to comment on the depressing but very real fact that
> >> British politics

> [...]

> >>
> > Under the Labour government the British National Party (a far right

> [...]
>
> Please stop.
>
> --
> Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
> Working, but not speaking, for XCOM Labs
> void Void(void) { Void(); } /* The recursive call of the void */
>

> Mut...@dastardlyhq.com via googlegroups.com
> 1 Apr 2023, 11:35 (3 days ago)
> to

>
>
> Not to bore anyone with parochial scottish politics, but practising christian
> Kate Forbes - who was also the most qualified candidate - was ditched by the
> woke mob when she revealed her admittedly 1950s views on certain topics.
>
> The irony of course is that Yousaf being a devout practising muslim who has
> even admitted consulting his imam on certain things and conveniently skipped a
> key vote on gay marriage suddenly became the prefered candidate.
>
> The real reason is he was the annointed successor to NS and the party machine
> simply used any opportunity to torpedo the opposition. Which they did.
>
>
>

> Mut...@dastardlyhq.com via googlegroups.com
> 1 Apr 2023, 11:36 (3 days ago)
> to

>
> On Fri, 31 Mar 2023 13:03:58 -0700

> Keith Thompson <Keith.S.T...@gmail.com> wrote:
> >Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >> On Friday, 31 March 2023 at 14:36:52 UTC+1, David Brown wrote:
> >>> It is one thing to comment on the depressing but very real fact that
> >>> British politics

> >[...]

> >>>
> >> Under the Labour government the British National Party (a far right

> >[...]
> >
> >Please stop.
>
> Yet its ok to discuss the xenophobic Scottish National Party?
>
>
>
>

> Mut...@dastardlyhq.com via googlegroups.com
> 1 Apr 2023, 11:45 (3 days ago)
> to

> Anssi Saari a...@sci.fi via googlegroups.com
> 08:12 (15 hours ago)
> to

>
> David Brown <david...@hesbynett.no> writes:
>
> > I don't know what you are disagreeing about - I /have/ fast and easy
> > access to the symbols used in common programming languages.
>
> And that's where we disagree. AltGr with anything isn't fast or easy in
> my opinion, it's good for those symbols used once a month or
> thereabouts. I get you don't get it, moving on.
>

> > I should really have been more careful about the OS in question. I
> > get lots of extra symbols on the standard Norwegian layout on Linux -
> > the standard Norwegian layout on Windows has more possibilities than
> > the standard UK/US English layout on Windows, but not nearly as much
> > as Linux. I would assume the Finnish layout is very similar to the
> > Norwegian layout on both systems.
>
> Seems reasonable. I guess I haven't really used other than US layout in
> Linux. I can't avoid Windows+Orifice even though my real HW work is all
> in Linux so the Windows Finnish layout is all I know.
>
> What provides the keyboard layouts in Linux, is it X with xkbset or do
> the various desktop environments provide their own?
>
>

> 'James Kuyper' via comp.lang.c++ <comp.l...@googlegroups.com>
> 16:30 (7 hours ago)
> to

>
> On 4/3/23 03:11, Anssi Saari wrote:
> > David Brown <david...@hesbynett.no> writes:
> >
> >> I don't know what you are disagreeing about - I /have/ fast and easy
> >> access to the symbols used in common programming languages.
> >
> > And that's where we disagree. AltGr with anything isn't fast or easy in
> > my opinion, it's good for those symbols used once a month or
> > thereabouts. I get you don't get it, moving on.
>
> According to the Wikipedia article on the AltGr key, it is usually
> mapped to a key that's in the same place as the right 'Alt' on many US
> keyboards, including my own.
> That article indicates that the common keyboard setup in Norway uses
> AltGr to display the following characters that I can type directly on my
> US keyboard: @${[]}~'. Of those 9 characters, there's only two that I
> can type without using the shift key. I just tried typing those
> characters using my right 'Alt' key as if I had a Norwegian keyboard
> set up. Except for 'AltGr'+'0' => '}', they weren't any harder to type
> than the shift sequences I needed for those same characters on a US
> keyboard.
> What makes you feel that the 'AltGr' key is so difficult to use that it
> should be used only once a month? Do you avoid using shifts, too?
>
>

> Scott Lurndal sc...@slp53.sl.home via googlegroups.com
> 17:12 (6 hours ago)
> to

>
>
> FWIW, one of the reasons I dislike camelcase is the need to use the
> shift key too frequently, and I type fast enough that the shift
> often sticks to the next keystroke which necessitates correction.
>
>

> Paavo Helde ees...@osa.pri.ee via googlegroups.com
> 19:40 (4 hours ago)
> to

[Jason Vas Dias]

So, it looks like we firstly need WGS21's P2621r2 recommendation to be implemented first:

https://wg21.link/p2621

I think it really is most unfortunate that the current C & C++ standards take such a
hard line on macro UTF-8 constant construction - why only UTF escapes ?

Why are UTF-8 escapes the ONLY thing meant to be checked inside macro expansions ?
This seems like a huge amount of complicated work CPP must do, checking all combinations
of input tokens at every phase of expansion for possible occurrences of unicode literal sequences.
Why ? What is so "dangerous" about constructing a UTF-8 sequence with a macro ?
I can understand why the backend might want to ignore / filter out any occurrences of change
of character order left->right <-> right->left, or horizontal layout <-> vertical layout,
or characters that eat or hide following characters, or invisible space characters that are not whitespace.
It seems to me that the backend compiler is in a much better position to do this
checking than is the pre-processor, or at least the pre-processor should do this
checking on the ultimate end result of expansion, not on intermediate stages.
Either a UTF-8 constant is an incorrect or a correct sequence - either way, the backend compiler should
be well equipped and prepared to deal with it.

This really needs to be addressed.

Secondly, as many respondents have pointed out, we have such an excellent alphabet
of mathematical + set theoretic + boolean logic symbols to use in modern UTF8 , yet are not permitted
to use any of them in our programs!

This really seems pathologically perverse & very silly.

I think compilers should have an option to read in a Unicode White-List text (XML?) file, listing characters or
ranges that are allowed in identifiers. This should really be very simple to do.

And CPP could be radically simplified and made more efficient if it did not have to do all that
"potential unicode constant token" checking for every stage of expansion - this is so expensive -
and what real dangers does it avoid ? I don't get it.

[James Kuyper]

On 4/4/23 00:02, Jason Vas Dias wrote:
> So, it looks like we firstly need WGS21's P2621r2 recommendation to be implemented first:
>
> https://wg21.link/p2621
>
> I think it really is most unfortunate that the current C & C++ standards take such a
> hard line on macro UTF-8 constant construction - why only UTF escapes ?
>
> Why are UTF-8 escapes the ONLY thing meant to be checked inside macro expansions ?
> This seems like a huge amount of complicated work CPP must do, checking all combinations
> of input tokens at every phase of expansion for possible occurrences of unicode literal sequences.

I'm curious - why would it have to do that? Which provisions of the
standards make you think that this is required? It occurs to me that you
may have misinterpreted what the standards require.

"if a splice results in a character sequence that matches the syntax of
a universal-character-name, the behavior is undefined." (C++ 5.2.1p2)
"If a character sequence that matches the syntax of a universal
character name is produced by token concatenation (6.10.3.3), the
behavior is undefined." (C 5.1.1.2p4, C++ 5.2.1p4)

Undefined behavior means that the standard imposes no requirements - in
particular, no requirement for checking universal character names. If
the standard had defined what the behavior was, that would require such
checking, but since it says that the behavior is undefined,
implementations are free to ignore the issue - just let happen whatever
would happen if they don't bother checking for that possibility.

UCNs in character and string literals are converted into the
corresponding member of the execution character set during translation
phase 5.

"A universal character name shall not specify a character whose short
identifier is less than 00A0 other than 0024 ( $ ), 0040 ( @ ), or 0060
(‘), nor one in the range D800 through DFFF inclusive. 78)" (C 6.4.3p2).
The 78 refers to footnote 78, which says "The disallowed characters are
the characters in the basic character set and the code positions
reserved by ISO/IEC 10646 for control characters, the character DELETE,
and the S-zone (reserved for use by UTF–16)."

"If a universal-character-name outside the c-char-sequence,
s-char-sequence, or r-char-sequence of a character-literal or
string-literal (in either case, including within a user-defined-literal)
corresponds to a control character or to a character in the basic source
character set, the program is ill-formed." (C++ 5.3p2)

Your original complaint was connected to the requirement that

"Each universal character name in an identifier shall designate a
character whose encoding in ISO/IEC 10646 falls into one of the ranges
specified in D.1. 75) The initial character shall not be a universal
character name designating a character whose encoding falls into one of
the ranges specified in D.2." (C 6.4.2.1p3).

"Each universal-character-name in an identifier shall designate a
character whose encoding in ISO/IEC 10646 falls into one of the ranges
specified in Table 2. The initial element shall not be a universal
character-name designating a character whose encoding falls into one of
the ranges specified in Table 3." (C++ 5.10p1).

Note that, in C, 'If a "shall" or "shall not" requirement that appears
outside of a constraint or runtime-constraint is violated, the behavior
is undefined.' (C 4p2). Thus, there is no obligation to diagnose
violations of this rule.

> Why ? What is so "dangerous" about constructing a UTF-8 sequence with a macro ?

It's not that it's dangerous, it's that defining the behavior of such a
construct would require precisely the kind of checking that you are
complaining about, and the committees did not want to impose a
requirement to perform such checking.

[Mut...@dastardlyhq.com]

On Mon, 3 Apr 2023 18:00:42 -0700 (PDT)
Jason Vas Dias <jason.v...@ptt.ie> wrote:
>Many thanks to all who responded !

> I've attached a small C header defining macros that allow you to do things
> like:
>
>'
>#include "M.h"
>
> U32_t

> dash_unicode_name =3D =F0=9D=95=8C8N(,,,,F,E,6,A);
> const char*
> dash=3D=F0=9F=99=B6(=F0=9D=95=8C8N=EF=B9=A9(,,,,F,E,6,A));
> inline U32_t
> dash_unicode()
> { return =F0=9D=95=8C=F0=9D=95=8D=EF=B9=A9=F0=9D=92=B7(&dash);
> }

Given this comes out as gibberish in both xterm and Mac Terminal and the
command line is an enviroment is where myself and others do a lot of their
development I would suggest you take this cretinous idea no further.

[Lynn McGuire]

ASCII, actually US-ASCII, is a USA specification. Other countries have
their own specifications.

USA -> https://en.wikipedia.org/wiki/ASCII

Other -> https://en.wikipedia.org/wiki/ASCII#Variants_and_derivations

Lynn

[Mut...@dastardlyhq.com]

Given the 'A' stands for American the clue is in the name. However ASCII
is the base 7 bit character set for almost all computers now.

>Other -> https://en.wikipedia.org/wiki/ASCII#Variants_and_derivations

If other counties want to screw around with the 7 bit version instead of
using extended 8 bit ascii or just code pages thats their lookout, but they
shouldn't expect it to be supported.

[Richard Damon]

The problem being that many of the transmission protocols in use were
only 7-bit protocols, so extended 8-bit "ASCII" wasn't really an option.
In fact, many of the protocols we use today still default to assuming
that machines can't handle 8-bit characters until it is negotiated that
both sides can use them.

It would be a bit arrogant to just presume that the rest of the world
would "make do" with standards that just didn't support their actual
needs. (And, to be honest, the US was to an extent, that arrogant, until
the world slapped them back).

[Mut...@dastardlyhq.com]

To be fair, making do was better than nothing at all. Not many countries
rushed out to build a computer industry. The UK obviously started it but got
overtaken (as usual) by the US after WW2, France and Russia (who nicked most of
the IP from the americans) had a go, but that was about it.

[james...@alumni.caltech.edu]

On Wednesday, April 5, 2023 at 3:26:25 AM UTC-4, Mut...@dastardlyhq.com wrote:
...

> >Other -> https://en.wikipedia.org/wiki/ASCII#Variants_and_derivations
>
> If other counties want to screw around with the 7 bit version instead of
> using extended 8 bit ascii or just code pages thats their lookout, but they
> shouldn't expect it to be supported.

Why shouldn't they expect it to be supported? It was in fact supported.

[David Brown]

On 03/04/2023 09:11, Anssi Saari wrote:
> David Brown <david...@hesbynett.no> writes:
>
>> I don't know what you are disagreeing about - I /have/ fast and easy
>> access to the symbols used in common programming languages.
>
> And that's where we disagree. AltGr with anything isn't fast or easy in
> my opinion, it's good for those symbols used once a month or
> thereabouts. I get you don't get it, moving on.

Sorry, are /you/ trying to tell /me/ that /I/ cannot conveniently use
the keyboard setup that I have used every day for decades? Don't you
think that I might be a better judge about what I can do quickly and easily?

Changing keyboard layouts takes time to get used to - regardless of what
you are changing from, or to. I can quite happily agree that if a
person is familiar with typing C code with a UK layout, then switching
to a Norwegian (or Finnish) layout will make them slow and inaccurate
for a while. But then you get used to it, and its fine. Seriously -
AltGr is really not any harder to press than Shift.

>
>> I should really have been more careful about the OS in question. I
>> get lots of extra symbols on the standard Norwegian layout on Linux -
>> the standard Norwegian layout on Windows has more possibilities than
>> the standard UK/US English layout on Windows, but not nearly as much
>> as Linux. I would assume the Finnish layout is very similar to the
>> Norwegian layout on both systems.
>

> Seems reasonable. I guess I haven't really used other than US layout in with

> Linux. I can't avoid Windows+Orifice even though my real HW work is all
> in Linux so the Windows Finnish layout is all I know.
>
> What provides the keyboard layouts in Linux, is it X with xkbset or do
> the various desktop environments provide their own?
>

I believe the top layer is X, though I don't know the details.
Different desktops can have their own settings applets for controlling
the options, but I assume they all affect the same X settings. The
basic keyboard layout doesn't need X. But my own experience is that I
either have a desktop with X, or the machine is a server or headless
system and I only need the keyboard for initial setup, so I have not had
the need to test much beyond ASCII outside of X.

[David Brown]

I can appreciate that reasoning - you are not the first person I have
heard say that using the shift key gets in the way of fluid typing.

My disagreement is with the idea that AltGr is significantly worse than
Shift in that respect.

[David Brown]

It is indeed a habit thing. I use my thumb of my right hand on the
AltGr key when typing {[]}. For some capital letters, I use the shift
with the same hand as I type the letter, for others I use the shift with
the opposite hand.

>
> Maybe it's different with Norwegian layout, they mentioned dead keys. On
> Estonian keyboard AltGr is a modifier which is not a dead key, so needs
> to be pressed simultaneously.
>

AltGr is a modifier key on the Norwegian layout - I think that is
standard. But ~, for example, is a dead key - in fact it is the AltGr
modifier on the key with ", ^ and ~ (which are all dead). To get the ~
symbol, I use AltGr with that key, then the space key. That is mildly
inconvenient, but not so that I notice it in use.

[Scott Lurndal]

The X server converts scan codes into keycodes. The mapping
is programmable (see, for example, setxkbmap(1) or xmodmap(1)).

[Jorgen Grahn]

On Mon, 2023-04-03, Anssi Saari wrote:
> David Brown <david...@hesbynett.no> writes:
>
>> I don't know what you are disagreeing about - I /have/ fast and easy
>> access to the symbols used in common programming languages.
>
> And that's where we disagree. AltGr with anything isn't fast or easy in
> my opinion, it's good for those symbols used once a month or
> thereabouts. I get you don't get it, moving on.

You're not disagreeing; you obviously use keyboards differently and
you're both happy with your setups.

Personally I'm in the US camp. If I had to work with a Swedish layout
I'd be slowed down and distracted -- when writing C++ code, but mainly
when doing Unix command line things.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Vir Campestris]

On 08/04/2023 09:33, Jorgen Grahn wrote:
> You're not disagreeing; you obviously use keyboards differently and
> you're both happy with your setups.
>
> Personally I'm in the US camp. If I had to work with a Swedish layout
> I'd be slowed down and distracted -- when writing C++ code, but mainly
> when doing Unix command line things.
>
> /Jorgen

If you want a challenge find a keyboard with a different layout to the
one you normally use, then set the keyboard mapping to a 3rd language.

I once had to use French keytops (AZERTY)
with a German mapping (QWERTZ).

It's got to be 20 years ago now, but I still have the scars.

Andy