usage of letter bases as alphabetic identifiers disallowed? #13044

p5pRT · 2013-06-21T02:03:18Z

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

Searchable as RT118563$

p5pRT · 2013-06-21T02:03:18Z

From [email protected]

Created by [email protected]

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 · 2013-06-21T03:44:17Z

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 · 2013-06-21T03:44:18Z

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

p5pRT · 2013-06-21T05:51:39Z

From [email protected]

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 · 2013-06-21T07:18:55Z

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 · 2013-06-21T08:13:06Z

From [email protected]

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 · 2013-06-21T12:30:35Z

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 · 2013-06-21T12:30:35Z

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 · 2013-06-21T12:30:35Z

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

p5pRT · 2013-06-21T16:56:56Z

From [email protected]

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 · 2013-06-21T17:05:20Z

From @Leont

On Fri, Jun 21, 2013 at 6:56 PM, Linda Walsh via RT
<perlbug-followup@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 · 2013-06-21T17:18:36Z

From [email protected]

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@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 · 2013-06-21T17:22:29Z

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 · 2013-06-21T17:24:19Z

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 · 2013-06-21T18:17:51Z

From @demerphq

On 21 June 2013 19:18, Linda Walsh via RT <perlbug-followup@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 · 2013-06-21T19:02:39Z

From @rjbs

* Linda Walsh via RT <perlbug-followup@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 · 2013-06-21T19:10:12Z

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 · 2013-06-21T20:29:46Z

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 4c10608 and
9c1129c

Karl Williamson

p5pRT · 2013-06-25T00:27:18Z

From [email protected]

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.

p5pRT closed this as completed Jun 21, 2013

p5pRT added Severity Medium distro-Linux type-library labels Oct 19, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

usage of letter bases as alphabetic identifiers disallowed? #13044

usage of letter bases as alphabetic identifiers disallowed? #13044

p5pRT commented Jun 21, 2013

p5pRT commented Jun 21, 2013

p5pRT commented Jun 21, 2013

p5pRT commented Jun 21, 2013

p5pRT commented Jun 21, 2013

p5pRT commented Jun 21, 2013

p5pRT commented Jun 21, 2013

p5pRT commented Jun 21, 2013

p5pRT commented Jun 21, 2013

p5pRT commented Jun 21, 2013

p5pRT commented Jun 21, 2013

p5pRT commented Jun 21, 2013

p5pRT commented Jun 21, 2013

p5pRT commented Jun 21, 2013

p5pRT commented Jun 21, 2013

p5pRT commented Jun 21, 2013

p5pRT commented Jun 21, 2013

p5pRT commented Jun 21, 2013

p5pRT commented Jun 21, 2013

p5pRT commented Jun 25, 2013

usage of letter bases as alphabetic identifiers disallowed? #13044

usage of letter bases as alphabetic identifiers disallowed? #13044

Comments

p5pRT commented Jun 21, 2013

p5pRT commented Jun 21, 2013

From [email protected]

Created by [email protected]

p5pRT commented Jun 21, 2013

From @khwilliamson

p5pRT commented Jun 21, 2013

p5pRT commented Jun 21, 2013

From [email protected]

p5pRT commented Jun 21, 2013

From @ikegami

p5pRT commented Jun 21, 2013

From [email protected]

p5pRT commented Jun 21, 2013

From @rjbs

p5pRT commented Jun 21, 2013

From [Unknown Contact. See original ticket]

p5pRT commented Jun 21, 2013

p5pRT commented Jun 21, 2013

From [email protected]

p5pRT commented Jun 21, 2013

From @Leont

p5pRT commented Jun 21, 2013

From [email protected]

p5pRT commented Jun 21, 2013

From @nwc10

p5pRT commented Jun 21, 2013

From @ribasushi

p5pRT commented Jun 21, 2013

From @demerphq

p5pRT commented Jun 21, 2013

From @rjbs

p5pRT commented Jun 21, 2013

From @rjbs

p5pRT commented Jun 21, 2013

From @khwilliamson

p5pRT commented Jun 25, 2013

From [email protected]