lowercase v in %h=(v1=>'x') -- key becomes \001 instead?

[p5pRT]

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

Searchable as RT8454$

[p5pRT]

From wpiper@us.ibm.com

Created by wpiper@us.ibm.com

"v" followed by digits makes for a funny hash key -- the digits
become the key. This happens in the %h=( key=>value) syntax.
For instance​:

perl -w -e 'my %h=(v65=>"A?",v7=>"Beep",v63=>"? indeed");' \
  -e 'print keys %h'

Workaround is to quote the keys​: %h=("v7" => "no beep now");

Is "v" the magic? "V" is OK..

Same thing happens with 5.6.1 under DOS. Doesn't happen with
5.5.3 under AIX.

-piper
802-769-6400

Perl Info

Flags:
    category=core
    severity=low

Site configuration information for perl v5.6.0:

Configured by jtrzepac at Tue Jul 10 09:46:08 EDT 2001.

Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
  Platform:
    osname=solaris, osvers=2.5.1, archname=sun4-solaris
    uname='sunos tadzu 5.5.1 generic_103640-34 sun4m sparc sunw,sparcstation-20 '
    config_args=''
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=undef d_sfio=undef uselargefiles=define
    use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=define
  Compiler:
    cc='cc', optimize='-O', gccversion=
    cppflags='-DSOCKS -I/usr/prod/contrib/include'
    ccflags ='-DSOCKS -I/usr/prod/contrib/include'
    stdchar='unsigned char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4
    alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries:
    ld='cc', ldflags ='-L/opt/SUNWspro/SC4.2/lib -L/usr/prod/contrib/lib'
    libpth=/opt/SUNWspro/SC4.2/lib /lib /usr/lib /usr/ccs/lib /usr/prod/contrib/lib /usr/openwin/lib
    libs=-lsocket -lnsl -ldl -lm -lc -lcrypt -lsec -lsocks -lresolv
    libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
    cccdlflags='-KPIC', lddlflags='-G -L/opt/SUNWspro/SC4.2/lib -L/usr/prod/contrib/lib'

Locally applied patches:



@INC for perl v5.6.0:
    /usr/prod/contrib/lib/perl-5.6.0/sun4-solaris
    /usr/prod/contrib/lib/perl-5.6.0
    /usr/prod/contrib/lib/perl-5.6.0/site_perl/sun4-solaris
    /usr/prod/contrib/lib/perl-5.6.0/site_perl
    /usr/prod/contrib/lib/perl-5.6.0/site_perl
    .


Environment for perl v5.6.0:
    HOME=/afs/btv/u/wpiper
    LANG=en_US.ISO8859-1
    LANGUAGE (unset)
    LC_COLLATE=en_US.ISO8859-1
    LC_CTYPE=en_US.ISO8859-1
    LC_MESSAGES=C
    LC_MONETARY=en_US.ISO8859-1
    LC_NUMERIC=en_US.ISO8859-1
    LC_TIME=en_US.ISO8859-1
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)

PATH=/afs/btv/u/wpiper/bin:/usr/bin:/usr/dt/bin:/usr/openwin/bin:/bin:/usr/ucb:.:/afs/btv/u/wpiper/shells:/usr/prod/local/bin:/usr/prod/contrib/bin:/afs/btv.ibm.com/data/frame/bin:/afs/btv.ibm.com/data/rfdkps/bin:/usr/lpp/cmvc/bin:/afs/btv/data/express/bin/net/rs6000:/afs/watson/projects/d700/emi/bin:/afs/btv.ibm.com/data/n37v/software/gnu/bin:/usr/bin/X11:/afs/btv/data/a29v/prod/bin:/afs/btv/data/cds/.cds/cds2/vmp2.4_ic443_200003190706/tools/vampire/bin:/afs/btv/data/cds/.cds/cds10/ic443_isr20000420207/tools/dfII/bin:/afs/btv/data/cds/.cds/cds10/ic443_isr20000420207/tools.ibmrs/bin:/afs/btv/data/rfdkps/cad6/sequence/2000.4PR1/bin:/afs/btv/u/gschulb/auto_place_bin:/afs/btv/data/rfdkps/cad7/ansoft:/etc:/afs/btv/data/ams/btv/@sys/bin:/usr/afsws/bin:/usr/afsws/etc:/afs/btv/@sys/prod/contrib/bin:/usr/local:/usr/etc:/usr/local/bin:/usr/local/fvwm2
    PERL_BADLANG (unset)
    SHELL=/bin/ksh

[p5pRT]

From [Unknown Contact. See original ticket]

On Feb 7, William Piper said​:

"v" followed by digits makes for a funny hash key -- the digits
become the key. This happens in the %h=( key=>value) syntax.
For instance​:

Perl 5.6 supports v-strings ("version strings").

perl -w -e 'my %h=(v65=>"A?",v7=>"Beep",v63=>"? indeed");' \
-e 'print keys %h'

Workaround is to quote the keys​: %h=("v7" => "no beep now");

Is "v" the magic? "V" is OK..

So yes, the "v" is magical.

--
Jeff "japhy" Pinyan japhy@​pobox.com http​://www.pobox.com/~japhy/
RPI Acacia brother #734 http​://www.perlmonks.org/ http​://www.cpan.org/
** Look for "Regular Expressions in Perl" published by Manning, in 2002 **
<stu> what does y/// stand for? <tenderpuss> why, yansliterate of course.

[p5pRT]

From @schwern

On Thu, Feb 07, 2002 at 01​:47​:47PM -0500, Jeff 'japhy' Pinyan wrote​:

On Feb 7, William Piper said​:

"v" followed by digits makes for a funny hash key -- the digits
become the key. This happens in the %h=( key=>value) syntax.
For instance​:

Perl 5.6 supports v-strings ("version strings").

Shouldn't the => have caused the v65 bareword to be quoted?

  The => digraph is mostly just a synonym for the comma
  operator. It's useful for documenting arguments that come
  in pairs. As of release 5.001, it also forces any word to
  the left of it to be interpreted as a string.

$ perl -wle 'my %h = (b23 => 42); print keys %h'
b23

Should v-string magic override =>'s LHS autoquoting?

--

Michael G. Schwern <schwern@​pobox.com> http​://www.pobox.com/~schwern/
Perl Quality Assurance <perl-qa@​perl.org> Kwalitee Is Job One
Tasty, yet morally ambiguous.

[p5pRT]

From @JohnPeacock

Michael G Schwern wrote​:

Shouldn't the => have caused the v65 bareword to be quoted?

   The => digraph is mostly just a synonym for the comma
   operator\.  It's useful for documenting arguments that come
   in pairs\.  As of release 5\.001\, it also forces any word to
   the left of it to be interpreted as a string\.

$ perl -wle 'my %h = (b23 => 42); print keys %h'
b23

Should v-string magic override =>'s LHS autoquoting?

Except that the tokenizer has already created the v-string before it even
reaches the '=>'. Technically speaking, v-strings are strings (POK) so the =>
has nothing to do (and AFAIK there is no way to undo the v-string after the
fact).

This is a documentation issue more than anything else; don't use barewords with
a leading 'v' followed by digits unless you want a v-string.

John

--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

[p5pRT]

From @tamias

On Thu, Feb 07, 2002 at 02​:28​:21PM -0500, John Peacock wrote​:

Michael G Schwern wrote​:

Shouldn't the => have caused the v65 bareword to be quoted?

  The => digraph is mostly just a synonym for the comma
  operator\.  It's useful for documenting arguments that come
  in pairs\.  As of release 5\.001\, it also forces any word to
  the left of it to be interpreted as a string\.

$ perl -wle 'my %h = (b23 => 42); print keys %h'
b23

Should v-string magic override =>'s LHS autoquoting?

Except that the tokenizer has already created the v-string before it even
reaches the '=>'. Technically speaking, v-strings are strings (POK) so
the => has nothing to do (and AFAIK there is no way to undo the v-string
after the fact).

This is a documentation issue more than anything else; don't use
barewords with a leading 'v' followed by digits unless you want a
v-string.

Ugh. One more reason to dislike v-strings.

Ronald

[p5pRT]

From @jhi

On Thu, Feb 07, 2002 at 03​:10​:34PM -0500, Ronald J Kimball wrote​:

On Thu, Feb 07, 2002 at 02​:28​:21PM -0500, John Peacock wrote​:

Michael G Schwern wrote​:

Shouldn't the => have caused the v65 bareword to be quoted?

  The => digraph is mostly just a synonym for the comma
  operator\.  It's useful for documenting arguments that come
  in pairs\.  As of release 5\.001\, it also forces any word to
  the left of it to be interpreted as a string\.

$ perl -wle 'my %h = (b23 => 42); print keys %h'
b23

Should v-string magic override =>'s LHS autoquoting?

Except that the tokenizer has already created the v-string before it even
reaches the '=>'. Technically speaking, v-strings are strings (POK) so
the => has nothing to do (and AFAIK there is no way to undo the v-string
after the fact).

This is a documentation issue more than anything else; don't use
barewords with a leading 'v' followed by digits unless you want a
v-string.

Ugh. One more reason to dislike v-strings.

I wasn't aware one needed any more.
 

Ronald

--
$jhi++; # http​://www.iki.fi/jhi/
  # There is this special biologist word we use for 'stable'.
  # It is 'dead'. -- Jack Cohen

[p5pRT]

From @ysth

In article <20020207191209.GJ24358@​blackrider>, Michael Schwern wrote​:

On Thu, Feb 07, 2002 at 01​:47​:47PM -0500, Jeff 'japhy' Pinyan wrote​:

On Feb 7, William Piper said​:

"v" followed by digits makes for a funny hash key -- the digits
become the key. This happens in the %h=( key=>value) syntax.
For instance​:

Perl 5.6 supports v-strings ("version strings").

Shouldn't the => have caused the v65 bareword to be quoted?

  The => digraph is mostly just a synonym for the comma
  operator\.  It's useful for documenting arguments that come
  in pairs\.  As of release 5\.001\, it also forces any word to
  the left of it to be interpreted as a string\.

$ perl -wle 'my %h = (b23 => 42); print keys %h'
b23

Should v-string magic override =>'s LHS autoquoting?

Either it shouldn't or this should be mentioned in
(5.6.2) perldelta/Perl Source Incompatibilities.

I'm inclined to think that it shouldn't. The clincher to me is
that even if there is a sub b23, "b23 =>" is interpreted as "'b23',".

[p5pRT]

From @jhi

I'm inclined to think that it shouldn't. The clincher to me is
that even if there is a sub b23, "b23 =>" is interpreted as "'b23',".

.... and that's the way I think it should work​: the hash keys are
primarily strings, nothing fanciers. I think having to add the extra
() or the extra & is not too much to ask.

--
$jhi++; # http​://www.iki.fi/jhi/
  # There is this special biologist word we use for 'stable'.
  # It is 'dead'. -- Jack Cohen

[p5pRT]

From @JohnPeacock

Yitzchak Scott-Thoennes wrote​:

In article <20020207191209.GJ24358@​blackrider>, Michael Schwern wrote​:

On Thu, Feb 07, 2002 at 01​:47​:47PM -0500, Jeff 'japhy' Pinyan wrote​:

On Feb 7, William Piper said​:

"v" followed by digits makes for a funny hash key -- the digits
become the key. This happens in the %h=( key=>value) syntax.
For instance​:

Perl 5.6 supports v-strings ("version strings").

Shouldn't the => have caused the v65 bareword to be quoted?

 The => digraph is mostly just a synonym for the comma
 operator\.  It's useful for documenting arguments that come
 in pairs\.  As of release 5\.001\, it also forces any word to
 the left of it to be interpreted as a string\.

$ perl -wle 'my %h = (b23 => 42); print keys %h'
b23

Should v-string magic override =>'s LHS autoquoting?

Either it shouldn't or this should be mentioned in
(5.6.2) perldelta/Perl Source Incompatibilities.

As I pointed out, the tokenizer takes care of the v-string processing
before the => can get a chance to autoquote. And, since v-strings are
technically strings (POK), there is nothing for the autoquoting to do in
any case. There is nothing strange about a hash key being 'special',
whether you mean a v-string or UTF8.

I have a series of patches (which are too large to fit in this e-mail ;~)
which make v-strings into objects, and would allow the autoquoting to
deal with them differently.

John

--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

[p5pRT]

From @rgarcia

On 2002.02.07 22​:03 Jarkko Hietaniemi wrote​:

I'm inclined to think that it shouldn't. The clincher to me is
that even if there is a sub b23, "b23 =>" is interpreted as "'b23',".

.... and that's the way I think it should work​: the hash keys are
primarily strings, nothing fanciers. I think having to add the extra
() or the extra & is not too much to ask.

Note that hash subscripts don't understand vstrings :

  $ bleadperl -le '$h{"v1"}=42; print $h{v1}'
  42

Having => to quote vstrings is probably doable. (But this would be an
incompatible change.)

[p5pRT]

From @jhi

On Thu, Feb 07, 2002 at 10​:33​:44PM +0100, Rafael Garcia-Suarez wrote​:

On 2002.02.07 22​:03 Jarkko Hietaniemi wrote​:

I'm inclined to think that it shouldn't. The clincher to me is
that even if there is a sub b23, "b23 =>" is interpreted as "'b23',".

.... and that's the way I think it should work​: the hash keys are
primarily strings, nothing fanciers. I think having to add the extra

s/ers/er/

() or the extra & is not too much to ask.

Note that hash subscripts don't understand vstrings :

$ bleadperl -le '$h{"v1"}=42; print $h{v1}'
42

So.... anyone want to fix a yucky feature to be even more consistently
yucky? :-)

Having => to quote vstrings is probably doable. (But this would be an
incompatible change.)

For those who like their yuckiness the way it is. I don't care either
way because my personal approach to v-strings is the proverbial
10-foot pole.

--
$jhi++; # http​://www.iki.fi/jhi/
  # There is this special biologist word we use for 'stable'.
  # It is 'dead'. -- Jack Cohen

[p5pRT]

From @JohnPeacock

Rafael Garcia-Suarez wrote​:

On 2002.02.07 22​:03 Jarkko Hietaniemi wrote​:

I'm inclined to think that it shouldn't. The clincher to me is
that even if there is a sub b23, "b23 =>" is interpreted as "'b23',".

.... and that's the way I think it should work​: the hash keys are
primarily strings, nothing fanciers. I think having to add the extra
() or the extra & is not too much to ask.

Note that hash subscripts don't understand vstrings :

$ bleadperl -le '$h{"v1"}=42; print $h{v1}'

No, the *tokenizer* understands that anything in between the {}'s should be a
string (or quoted to become one) and hence the v-string code never comes into
play​:

$ perl5.7.2.exe -Dt -le '$h{"v1"}=42; print $h{v1}'

EXECUTING...

(-e​:0) enter
(-e​:0) nextstate
(-e​:1) const(IV(42))
(-e​:1) gv(main​::h)
(-e​:1) rv2hv
(-e​:1) const(PVIV("v1")) <- string
(-e​:1) helem
(-e​:1) sassign
(-e​:1) nextstate
(-e​:1) pushmark
(-e​:1) gv(main​::h)
(-e​:1) rv2hv
(-e​:1) const(PVIV("v1")) <- also string
(-e​:1) helem
(-e​:1) print
42
(-e​:1) leave

The v-string path is only used when the token is potentially a number, which is
never the case with hash keys. This, however, shows that v-strings *can* be
used as hash keys​:

$ perl5.7.2.exe -le '$key = v1; $h{$key}=42; print $h{$key}'

EXECUTING...

(-e​:0) enter
(-e​:0) nextstate
(-e​:1) const(PV("\1"\0)) <- v-string
(-e​:1) gvsv(main​::key)
(-e​:1) sassign
(-e​:1) nextstate
(-e​:1) const(IV(42))
(-e​:1) gv(main​::h)
(-e​:1) rv2hv
(-e​:1) gvsv(main​::key)
(-e​:1) helem
(-e​:1) sassign
(-e​:1) nextstate
(-e​:1) pushmark
(-e​:1) gv(main​::h)
(-e​:1) rv2hv
(-e​:1) gvsv(main​::key)
(-e​:1) helem
(-e​:1) print
42
(-e​:1) leave

Having => to quote vstrings is probably doable. (But this would be an
incompatible change.)

I'm doubtful that it would be extremely doable because it would involve backing
up and reparsing the prior token as a string as opposed to a number.

John

--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

[p5pRT]

From @tamias

On Thu, Feb 07, 2002 at 05​:04​:11PM -0500, John Peacock wrote​:

Rafael Garcia-Suarez wrote​:

On 2002.02.07 22​:03 Jarkko Hietaniemi wrote​:

I'm inclined to think that it shouldn't. The clincher to me is
that even if there is a sub b23, "b23 =>" is interpreted as "'b23',".

.... and that's the way I think it should work​: the hash keys are
primarily strings, nothing fanciers. I think having to add the extra
() or the extra & is not too much to ask.

Note that hash subscripts don't understand vstrings :

$ bleadperl -le '$h{"v1"}=42; print $h{v1}'

No, the *tokenizer* understands that anything in between the {}'s should be
a
string (or quoted to become one) and hence the v-string code never comes
into
play​:

$ perl5.7.2.exe -Dt -le '$h{"v1"}=42; print $h{v1}'

[snip]

The v-string path is only used when the token is potentially a number, which
is
never the case with hash keys. This, however, shows that v-strings *can* be
used as hash keys​:

$ perl5.7.2.exe -le '$key = v1; $h{$key}=42; print $h{$key}'

This is inconsistent with the behavior of numeric literals as hash keys​:

% perl -le '$h{"01"}=42; $h{1} = 1; print $h{01}'
1

Ronald

[p5pRT]

From @JohnPeacock

Ronald J Kimball wrote​:

$ perl5.7.2.exe -le '$key = v1; $h{$key}=42; print $h{$key}'

This is inconsistent with the behavior of numeric literals as hash keys​:

% perl -le '$h{"01"}=42; $h{1} = 1; print $h{01}'
1

It's not, because the numeric case jumps directly to scan_num()​:

toke.c​:3595

  /* FALL THROUGH */
  case '0'​: case '1'​: case '2'​: case '3'​: case '4'​:
  case '5'​: case '6'​: case '7'​: case '8'​: case '9'​:
  s = scan_num(s, &yylval);

....

whereas the 'v1' case goes here​:

toke.c​:3680

  case 'v'​:
  if (isDIGIT(s[1]) && PL_expect != XOPERATOR) {
  char *start = s;
  start++;
  start++;
  while (isDIGIT(*start) || *start == '_')
  start++;
  if (*start == '.' && isDIGIT(start[1])) {
  s = scan_num(s, &yylval);
  TERM(THING);
  }
  /* avoid v123abc() or $h{v1}, allow C<print v10;> */
  else if (!isALPHA(*start) && (PL_expect == XTERM || PL_expect ==
XREF || PL_expect == XSTATE)) {

Notice that line above the 'else if' where hash keys are special cased. If I am
following the twisting around her, both the if and else if fail in our case and
  PL_tokenbuf contains the 'v1' as a string, which is what is taken as the key.

John

--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

[p5pRT]

From @tamias

On Thu, Feb 07, 2002 at 10​:44​:22PM -0500, John Peacock wrote​:

Ronald J Kimball wrote​:

$ perl5.7.2.exe -le '$key = v1; $h{$key}=42; print $h{$key}'

This is inconsistent with the behavior of numeric literals as hash keys​:

% perl -le '$h{"01"}=42; $h{1} = 1; print $h{01}'
1

It's not, because the numeric case jumps directly to scan_num()​:

I'd afraid I don't understand. I point out that it's inconsistent because
the behavior is different. You respond that it's not inconsistent, because
the implementation is different.

%h = ( 01 => 1 ) sets $h{'1'} to 1.
$h{01} accesses $h{'1'}.

%h = ( v1 => 1 ) sets $h{"\cA"} to 1.
$h{v1} accesses $h{'v1'}.

Ronald