usage of letter bases as alphabetic identifiers disallowed?

[p5pRT]

Migrated from rt.perl.org#118563 (status was 'resolved')

Searchable as RT118563$

[p5pRT]

From perl-diddler@tlinx.org

Created by perl-diddler@tlinx.org

I was attempting to clean up some code and tried to use a foreign phoneme\, or word or letter base\, specifically\, "·" (U+00B7 MIDDLE DOT) in an identifier in perl\, but got a syntax error.

---sample program---

#!/usr/bin/perl -w use 5.16.0; use utf8;

my $·=1;

---end---

Everything I read on the internet describe the above as being part of a word or identifier\, and it has the properties Diacritic\, Extender\, Grapheme Base\, ID Continue XID Continue.

As near as I can tell in looking at definitions for Grapheme base\, it seems it is something that would be part of a word or identifier -- having a similar function to a letter.

It's not an operator\, and it's not punctuation. So is it an oversite that is causing it to be flagged as a warning? Or what's up... Truth be known\, I was actually trying to define it with "use constant" (thus as a sub) defined as "." (a single period or dot) so my joined strings didn't look so tacky.

  use constant host => Subsite .".". Site ."​:". port;  
could be something like​:

  use constant host => subsite .·. Site .：. port;

if graphemes were able to be included...

It seemed like this could be an oversight\, but if not\, I'd like to have it be an RFE for including such in varnames/sub names...

Tnx. Going back to find some other char to use instead...sigh.

Perl beautification -- a truely thankless task.

Perl Info

``` Flags: category=library severity=medium module=constant This perlbug was built using Perl 5.16.2 - Fri Feb 15 01:17:37 UTC 2013 It is being executed now by Perl 5.16.2 - Fri Feb 15 01:12:05 UTC 2013. Site configuration information for perl 5.16.2: Configured by abuild at Fri Feb 15 01:12:05 UTC 2013. Summary of my perl5 (revision 5 version 16 subversion 2) configuration: Platform: osname=linux, osvers=3.4.6-2.10-default, archname=x86_64-linux-thread-multi uname='linux build34 3.4.6-2.10-default #1 smp thu jul 26 09:36:26 utc 2012 (641c197) x86_64 x86_64 x86_64 gnulinux ' config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Dd_dbm_open -Duseshrplib=true -Doptimize=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe -Accflags=-DPERL_USE_SAFE_PUTENV -Dotherlibdirs=/usr/lib/perl5/site_perl' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe', cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector' ccversion='', gccversion='4.7.2 20130108 [gcc-4_7-branch revision 195012]', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib64 -fstack-protector' libpth=/lib64 /usr/lib64 /usr/local/lib64 libs=-lm -ldl -lcrypt -lpthread perllibs=-lm -ldl -lcrypt -lpthread libc=/lib64/libc-2.17.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.17' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.16.2/x86_64-linux-thread-multi/CORE' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib64 -fstack-protector' Locally applied patches: @INC for perl 5.16.2: /home/law/bin/lib /usr/lib/perl5/site_perl/5.16.2/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.16.2 /usr/lib/perl5/vendor_perl/5.16.2/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.16.2 /usr/lib/perl5/5.16.2/x86_64-linux-thread-multi /usr/lib/perl5/5.16.2 /usr/lib/perl5/site_perl/5.16.2/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.16.2 /usr/lib/perl5/site_perl . Environment for perl 5.16.2: HOME=/home/law LANG=en_US.UTF-8 LANGUAGE (unset) LC_COLLATE=C LC_CTYPE=en_US.UTF-8 LD_LIBRARY_PATH=/usr/lib64/mpi/gcc/openmpi/lib64 LOGDIR (unset) PATH=.:/home/law/bin/lib:/sbin:/usr/local/sbin:/usr/lib64/mpi/gcc/openmpi/bin:/home/law/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/lib/qt3/bin:/opt/dell/srvadmin/bin:/usr/sbin:/etc/local/func_lib:/home/law/lib PERL5OPT=-CSA -I/home/law/bin/lib PERL_BADLANG (unset) SHELL=/bin/bash ```

[p5pRT]

From @khwilliamson

On 06/20/2013 08​:03 PM\, Linda Walsh (via RT) wrote​:

# New Ticket Created by Linda Walsh # Please include the string​: [perl #118563] # in the subject line of all future correspondence about this issue. # \<URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=118563 >

This is a bug report for perl from perl-diddler@​tlinx.org\, generated with the help of perlbug 1.39 running under perl 5.16.2.

----------------------------------------------------------------- [Please describe your issue here]

I was attempting to clean up some code and tried to use a foreign phoneme\, or word or letter base\, specifically\, "·" (U+00B7 MIDDLE DOT) in an identifier in perl\, but got a syntax error.

---sample program---

#!/usr/bin/perl -w use 5.16.0; use utf8;

my $·=1;

First of all\, you have 00B7 as the first character in an identifier which is ID Start\, not ID continue character; so to be valid it should be something like

  my $foo·=1;

But this doesn't work either\, see below.

---end---

Everything I read on the internet describe the above as being part of a word or identifier\, and it has the properties Diacritic\, Extender\, Grapheme Base\, ID Continue XID Continue.

As near as I can tell in looking at definitions for Grapheme base\, it seems it is something that would be part of a word or identifier -- having a similar function to a letter.

It's not an operator\, and it's not punctuation. So is it an oversite that is causing it to be flagged as a warning?

Actually\, it IS punctuation\, and therein lies the problem. Its general category is "Other Punctuation". This is a bug in the Unicode standard\, and they are aware of it. A punctuation character should not be in the middle of an identifier\, so Perl uses a slightly modified version of ID Continue. Perl's version requires an IDCont character to also match \w.

The problem in Unicode is longstanding\, and there have been some recent steps toward a resolution. It stems from a mistake early on. The middle dot here is used for both the Catalan language where it isn't punctuation and can be in the middle of a word; and Greek\, where it is equivalent to the English semi-colon. To use an analogy\, they are trying to have the same character be both a floor wax and a dessert topping. They should be two separate characters\, but their representations as middle dots are indistinguishable.

I think perldata could be changed to talk about this subtlety.

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From perl-diddler@tlinx.org

On Thu Jun 20 20​:44​:17 2013\, public@​khwilliamson.com wrote​:

First of all\, you have 00B7 as the first character in an identifier which is ID Start\, not ID continue character; so to be valid it should be something like

my $foo�=1;

But this doesn't work either\, see below.

---

I wondered about that...

---end---

As near as I can tell in looking at definitions for Grapheme base\, it seems it is something that would be part of a word or identifier -- having a similar function to a letter.

It's not an operator\, and it's not punctuation. So is it an oversite that is causing it to be flagged as a warning?

Actually\, it IS punctuation\, and therein lies the problem. Its general category is "Other Punctuation". This is a bug in the Unicode standard\, and they are aware of it.

---

I see it was introduced in 1.0.0 Also under Line Break\, it has Al [Ambiguous (alphabetic or Ideographic)]

But I see the general category now as well... I'd focused on properties...

equivalent to the English semi-colon. To use an analogy\, they are trying to have the same character be both a floor wax and a dessert topping. They should be two separate characters\, but their representations as middle dots are indistinguishable.

I think perldata could be changed to talk about this subtlety.

---

Hmmm... I can understand the need for the subtlety in RE matching\, but for purposes of a language identifier it seems like the syntax could be a bit more liberal.

I haven't tried it but I suspect (?) that a pictograph isn't considered alphabetic either? But if that's the case\, then what about Egyptian hieroglyphs which are also called pictographic?

The little smiley faces...such logic would also include them as written symbols that we attach meaning to. To be *alpha*Beta-ic\, might the only real languages that qualify be western or in its strictest sense greek and close cousins?

[p5pRT]

From @ikegami

On Fri\, Jun 21\, 2013 at 1​:51 AM\, Linda Walsh via RT \< perlbug-followup@​perl.org> wrote​:

I haven't tried it but I suspect (?) that a pictograph isn't considered alphabetic either? But if that's the case\, then what about Egyptian hieroglyphs which are also called pictographic?

$ uniprops U+13000 U+13000 ‹𓀀› \N{EGYPTIAN HIEROGLYPH A001}   \w \pL \p{L_} \p{Lo}   All Any Alnum Alpha Alphabetic Assigned InEgyptianHieroglyphs Egyptian_Hieroglyphs   Is_Egyptian_Hieroglyphs Egyp L Lo Gr_Base Grapheme_Base Graph GrBase ID_Continue IDC ID_Start IDS   Letter L_ Other_Letter Print Word XID_Continue XIDC XID_Start XIDS X_POSIX_Alnum X_POSIX_Alpha   X_POSIX_Graph X_POSIX_Print X_POSIX_Word

$ perl -CS -e'print "use utf8; \$\N{U+13000}=123; print \"\$\N{U+13000}\\n\";\n";' use utf8; $𓀀=123; print "$𓀀\n";

$ perl -CS -e'print "use utf8; \$\N{U+13000}=123; print \"\$\N{U+13000}\\n\";\n";' | perl 123

(5.14.2)

[p5pRT]

From perl-diddler@tlinx.org

So if Hieroglyphs are allowed\, then shouldn't also be allowed\, ideographs & pictographic symbols? These all have the grapheme base property=TRUE\, and are also specified for use as symbols.

perl -e 'use 5.16.0; use utf8; my $🌞 =12; # sun U+1F31E my $🔒=1; # lock 1F512 my $🔝=2; # Top^ 1F51D my $🙊=3; # speak-no-evil monkey U+1F63D my $🝣=4; # alchemical purify U+1F763 ' Can't use global $🌞 in "my" at -e line 2\, near "my $🌞" Can't use global $🔒 in "my" at -e line 3\, near "my $🔒" Can't use global $🔝 in "my" at -e line 4\, near "my $🔝" Can't use global $🙊 in "my" at -e line 5\, near "my $🙊" Can't use global $🝣 in "my" at -e line 6\, near "my $🝣" Execution of -e aborted due to compilation errors.

---

[p5pRT]

From @rjbs

No. They are not XID Start characters\, nor word\, nor POSIX punctuation.

perldata specifies fairly precisely the rules in effect. The middle dot problem was a subtle problem with the character\, but hieroglyphs are not.

-- rjbs

[p5pRT]

From [Unknown Contact. See original ticket]

No. They are not XID Start characters\, nor word\, nor POSIX punctuation.

perldata specifies fairly precisely the rules in effect. The middle dot problem was a subtle problem with the character\, but hieroglyphs are not.

-- rjbs

[p5pRT]

@rjbs - Status changed from 'open' to 'resolved'

[p5pRT]

From perl-diddler@tlinx.org

On Fri Jun 21 05​:30​:35 2013\, rjbs wrote​:

No. They are not XID Start characters\, nor word\, nor POSIX punctuation.

perldata specifies fairly precisely the rules in effect. The middle dot problem was a subtle problem with the character\, but hieroglyphs are not.

---

Did you close this because you thought you honestly thought your answer provided resolution to the issue of the poster\, or did you just wish to demonstrate your wide repertoire in dealing with things you don't like.

The original post said that even if the current rules are such that various chars are invalid\, that this be considered an RFE to widen that range.

Can you explain how you thought your answer provided resolution? You refer to perl data as being authoritative\, yet it doesn't mention 'word' nor POSIX nor XID start characters.

perldata clearly says identifiers are not 'word' nor 'posix'\, nor 'xid start characters'\, it says they are letters. Graphemes are letters. The characters I listed are all graphemes and are *symbols* -- perfect for use as symbols in a language as they can encompass an entire idea.

So if graphemes are letters (nothing about words) how can can they not also be *considered* for use in symbols (when they graphemes in question are called symbols?)...

Can you explain how your answer was supposed to make sense in light of what perldata says "fairly precisely"... Since it fairly precisely doesn't say anything about the words you use to identify\, presumably\, what identifiers should be (that these characters are not\, and thus shouldn't be suitable).

I don't see that your answer really resolves anything regarding the original issue other than communicating a response of "I don't want want to entertain anything you have to say\, or any idea you have to share. [Go away]."

[p5pRT]

From @Leont

On Fri\, Jun 21\, 2013 at 6​:56 PM\, Linda Walsh via RT \perlbug\-followup@&#8203;perl\.org wrote​:

Did you close this because you thought you honestly thought your answer provided resolution to the issue of the poster\, or did you just wish to demonstrate your wide repertoire in dealing with things you don't like.

Linda\, your hostility is not appreciated. Ricardo does not deserve this kind of crap targeted against him.

Leon

[p5pRT]

From perl-diddler@tlinx.org

On Fri Jun 21 10​:05​:20 2013\, LeonT wrote​:

On Fri\, Jun 21\, 2013 at 6​:56 PM\, Linda Walsh via RT \perlbug\-followup@&#8203;perl\.org wrote​:

Did you close this because you thought you honestly thought your answer provided resolution to the issue of the poster\, or did you just wish to demonstrate your wide repertoire in dealing with things you don't like.

Linda\, your hostility is not appreciated.

---

hostility? Sorry\, honesty often comes off has hostile. Why do you think they shoot the messangers?

Ricardo does not deserve this kind of crap targeted against him.

---

He seems have taken a leadership role of targeted crap against me.

BTW\, your response is a perfect example how snipers are protected by the community. His response provided no factual justification for calling this issue resolved -- and even by conservative description\, would easily qualify as a hit & run sniping attack.

Defending such actions reflects on the wider list membership as being equally thoughtful\, perhaps more so as they obfuscate the trite treatment demonstrated.

[p5pRT]

From @nwc10

On Fri\, Jun 21\, 2013 at 09​:56​:56AM -0700\, Linda Walsh via RT wrote​:

On Fri Jun 21 05​:30​:35 2013\, rjbs wrote​:

No. They are not XID Start characters\, nor word\, nor POSIX punctuation.

perldata specifies fairly precisely the rules in effect. The middle dot problem was a subtle problem with the character\, but hieroglyphs are not. ----

Did you close this because you thought you honestly thought your answer provided resolution to the issue of the poster\, or did you just wish to demonstrate your wide repertoire in dealing with things you don't like.

The original post said that even if the current rules are such that various chars are invalid\, that this be considered an RFE to widen that range.

People who are seriously requesting enhancements do so POLITELY\, not in an extremely hostile passive aggressive tone.

You have already suggested a perfectly reasonable explanation as to why Ricardo closed the ticket - because he considered that he had answered it satisfactorily.

[snip potentially reasonable questions in a quite unreasonable tone of voice]

I don't see that your answer really resolves anything regarding the original issue other than communicating a response of "I don't want want to entertain anything you have to say\, or any idea you have to share. [Go away]."

That is not the case.

We do not wish to continue tolerating your unambiguously unacceptable manner of communication.

You have continually demonstrated an ability to attribute the worst possible motives to people\, and use polite but pretty unpleasant language to express it. Most everyone else communicating on this list doesn't do this. The common thread here is YOU\, not Ricardo\, not anyone else.

Yet you are incapable of the introspection needed to realise this.

Ricardo is a volunteer. You OWE him\, not he owes you\, but this is not how you treat him (or anyone else).

I had held out hope that whatever you felt privately\, you would be capable of moderating your communication to something which approaches the social norms. This is clearly not the case.

As you think that Ricardo has some sort of grudge\, let me make it clear that *I* will request that the perl.org sysadmins block you. He is not in the minority of one here. You are.

Nicholas Clark

[p5pRT]

From @ribasushi

On Fri\, Jun 21\, 2013 at 09​:56​:56AM -0700\, Linda Walsh via RT wrote​:

perldata clearly says identifiers are not 'word' nor 'posix'\, nor 'xid start characters'\, it says they are letters.

ORLY?! Allow me to quote [1]

  Identifier parsing   Up until Perl 5.18\, the actual rules of what a valid identifier was   were a bit fuzzy. However\, in general\, anything defined here should   work on previous versions of Perl\, while the opposite -- edge cases   that work in previous versions\, but aren't defined here -- probably   won't work on newer versions. As an important side note\, please note   that the following only applies to bareword identifiers as found in   Perl source code\, not identifiers introduced through symbolic   references\, which have much fewer restrictions.   ...

I do agree that the doc could use some clarification - I am pretty sure p5p would welcome patches to this effect.

Also (for the sake of everyone on the list\, not just mine) I would like to preempt this thread from continuing in the spirit of "Gah... I see the docs now\, but they do not agree with my reality. Let's change the docs and and the interpeter to fit my preestablished misconceptions".

In the spirit of such preemptiion​: Linda\, if you feel it is appropriate to take the discussion in this direction - I am sorry\, it is not appropriate[2].

Cheers

[1] https://metacpan.org/module/RJBS/perl-5.18.0/pod/perldata.pod#Identifier-parsing

[2] It would only be appropriate if you read up on at least a small portion of the can of worms labeled "unicode in Perl identifiers"

[p5pRT]

From @demerphq

On 21 June 2013 19​:18\, Linda Walsh via RT \perlbug\-followup@&#8203;perl\.org wrote​:

BTW\, your response is a perfect example how snipers are protected by the community. His response provided no factual justification for calling this issue resolved -- and even by conservative description\, would easily qualify as a hit & run sniping attack.

Ricardo is not a sniper. He is the President (spelled Pumpking). See pod/perlpolicy​:

=head2 Perl 5 Porters

Subscribers to perl5-porters (the porters themselves) come in several flavours. Some are quiet curious lurkers\, who rarely pitch in and instead watch the ongoing development to ensure they're forewarned of new changes or features in Perl. Some are representatives of vendors\, who are there to make sure that Perl continues to compile and work on their platforms. Some patch any reported bug that they know how to fix\, some are actively patching their pet area (threads\, Win32\, the regexp -engine)\, while others seem to do nothing but complain. In other words\, it's your usual mix of technical people.

Over this group of porters presides Larry Wall. He has the final word in what does and does not change in any of the Perl programming languages. These days\, Larry spends most of his time on Perl 6\, while Perl 5 is shepherded by a "pumpking"\, a porter responsible for deciding what goes into each release and ensuring that releases happen on a regular basis.

Larry sees Perl development along the lines of the US government​: there's the Legislature (the porters)\, the Executive branch (the -pumpking)\, and the Supreme Court (Larry). The legislature can discuss and submit patches to the executive branch all they like\, but the executive branch is free to veto them. Rarely\, the Supreme Court will side with the executive branch over the legislature\, or the legislature over the executive branch. Mostly\, however\, the legislature and the executive branch are supposed to get along and work out their differences without impeachment or court cases.

=cut

cheers Yves

-- perl -Mre=debug -e "/just|another|perl|hacker/"

[p5pRT]

From @rjbs

* Linda Walsh via RT \perlbug\-followup@&#8203;perl\.org [2013-06-21T12​:56​:56]

On Fri Jun 21 05​:30​:35 2013\, rjbs wrote​:

No. They are not XID Start characters\, nor word\, nor POSIX punctuation.

perldata specifies fairly precisely the rules in effect. The middle dot problem was a subtle problem with the character\, but hieroglyphs are not. ----

Did you close this because you thought you honestly thought your answer provided resolution to the issue of the poster

Yes.

The question was about the problem with U+00b7\, which was a complex case\, and this was answered. The second\, separate\, question was about hieroglyphics and "pictographs." I explained that in almost all cases\, the documentation in perldata applies\, that you had initially found an exception\, but that no such exception applied to hieroglyphics. As I said\, the question in the general case is about XID and XIDC.

The original post said that even if the current rules are such that various chars are invalid\, that this be considered an RFE to widen that range.

My reading of this was that it was rendered irrelevant by the explanation that it was failing only because of a corner case. The correct grammar for identifiers was discussed on p5p some time (about a year?) ago\, with the current set of rules proposed\, discussed\, refined\, and decided on.

They are also\, fortunately\, close to what should be expected​: they're XID-based\, except for where they must respect backward compatibility.

perldata clearly says identifiers are not 'word' nor 'posix'\, nor 'xid start characters'\, it says they are letters. Graphemes are letters. The characters I listed are all graphemes and are *symbols* -- perfect for use as symbols in a language as they can encompass an entire idea.

I find this hard to reply to. Graphemes are graphemes. They are not necessarily letters or symbols. For example U+00A0 is a Grapheme_Base character and neither a letter nor a symbol\, but a separator. I'm not sure exactly how you're using these terms. In the context of Unicode characters\, they are well-defined\, and it seems like you're not using that definition.

At any rate\, the existing rules were already hashed out with discussion\, analysis\, and testing. If you want to propose very specific changes to the grammar\, with specific reasoning\, you may — but I think it's going to be an uphill battle. Sticking to the rules in annex #31 is likely the way forward\, as much as is reasonable.

I don't see that your answer really resolves anything regarding the original issue other than communicating a response of "I don't want want to entertain anything you have to say\, or any idea you have to share. [Go away]."

I thought the issue had been explained prior to my answer.

-- rjbs

[p5pRT]

From @rjbs

no such exception applied to hieroglyphics. As I said\, the question in the general case is about XID and XIDC.

I've confused myself a bit in this reply​: hieroglyphics *are* XID\, but not the alchemical symbol and others that you mentioned.

-- rjbs

[p5pRT]

From @khwilliamson

Thanks for the original report. perldata has now been corrected to note that an identifier continuation character must also be a \w.

Commits 4c1060812937b8380199ef84b4b2c10c384b7bc7 and 9c1129c7de15ff8044f606550980c47f8c1724e9

---

Karl Williamson

[p5pRT]

From perl-diddler@tlinx.org

On Fri Jun 21 10​:24​:19 2013\, rabbit-p5p@​rabbit.us wrote​:

Identifier parsing Up until Perl 5.18\, the actual rules of what a valid identifier was were a bit fuzzy.

---

  Please note\, my bug report was against 5.16.2. If you feel 5.18.0 has made my request for wider latitude in perl identifers moot\, I am more than happy. Are you saying the cases I mentioned above work in 5.18.0? If not\, I'm not sure the situation has been improved.

Perl source code\, not identifiers introduced through symbolic references\, which have much fewer restrictions.

---

  That doesn't seem inconsistent to you? Or.. why is that? How are they different? You mention 5.18 being different than 5.16\, so before you become irritated with my not reading the 5.18 docs\, realize this bug is from someone still using 5.16.2. If a section in the 5.18 docs explains this reasoning\, please let me know which section(s) I should read to update my knowledge to the current release.

Also (for the sake of everyone on the list\, not just mine) I would like to preempt this thread from continuing in the spirit of "Gah... I see the docs now\, but they do not agree with my reality. Let's change the docs and and the interpeter to fit my preestablished misconceptions".

---

Actually\, it wouldn't be about them fitting my pre-established misconceptions. I'm saying the behavior in 5.16.2 doesn't match what I would like to see in terms of usability. If there are technical reasons that prevent that\, I would love to learn about them.

In the spirit of such preemptiion​: Linda\, if you feel it is appropriate to take the discussion in this direction - I am sorry\, it is not appropriate [.It would only be appropriate if you read up on at least a small portion of the can of worms labeled "unicode in Perl identifiers"]

---

  If you are referring to the URL you quote​:

[https://metacpan.org/module/RJBS/perl-5.18.0/pod/perldata.pod#Identifier-parsing]

  I see why Ricardo would say what he said\, though that he would answer a bugreport against 5.16.2 with assumed references to a doc not referenced\, seems cryptic at best. Just because 5.18 has certain rules doesn't mean those should be the final rules. Note\, the 5.18 discussion was a closed discussion and public discussion wasn't not allowed. To expect public buy-in\, on something they had no input into seems to be on the presumptive and possibly rude side. Also\, for my own sake\, I would like to read up on what the difference is between XID and ID and what makes for the decision to classify a character as such. It may well be that the unicode standard needs updating\, since I don't see why modern ideographics should be excluded while historical ones are included in the XID range.

  As for various other responses\, I'm not sure how I can handle the ones of intense passion\, other than to wish for your healing that my language not be so disturbing to you. It sure seems like there is a problem of over-reaction to what has been characterized as polite but unpleasant\, or extremely hostile passive aggressive tone. Interesting that women's communications are often described by others are passive aggressive\, yet that no one possible would give the slightest credibility that the attitudes of a few 'aggressive' types\, demonstrated on this list might have anything rooted in sexism.

  As for my ascribing the worst possible motives to people who exclude me from participation -- that's fairly normal. That's why in general\, in government we like openness and transparency.

  Also\, at least\, two people brought up the idea of Ricardo being a volunteer -- like that has some inherent meaning that I should know. I'm a volunteer too\, and I try to treat other volunteers as I am treated -- I have been trying to use how I am treated as a minimum bar for how I should treat others -- was that your point?

Sorry if my words sound unambiguously unacceptable... but I think a large part of hearing of them is in the ear of the listener.