Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFE: "qqw( $var/x $var/y word3 $var4=word4 )" #15209

Closed
p5pRT opened this issue Mar 2, 2016 · 23 comments
Closed

RFE: "qqw( $var/x $var/y word3 $var4=word4 )" #15209

p5pRT opened this issue Mar 2, 2016 · 23 comments

Comments

@p5pRT
Copy link

@p5pRT p5pRT commented Mar 2, 2016

Migrated from rt.perl.org#127640 (status was 'rejected')

Searchable as RT127640$

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 2, 2016

From perl-diddler@tlinx.org

Created by perl-diddler@tlinx.org

Every once in a while, I start filling an array using
"qw()", when I run into, not too infrequently, a desire
to have a var or expression as a "word". Paths can be
a good example​:

my short_paths=[ qw( sysfs sys_classes netclass sysmods) ];
my spth_vals =[qqw( /sys $sysfs/class $sys_classes/net $sysfs/module ) ];
--
or the standard config path depency chain​:

: ${prefix​:=/}
: ${bootprefix​:=${prefix}}
: ${eprefix​:=${prefix}usr}
: ${bindir=$eprefix/bin}
: ${sbindir​:=$eprefix/sbin}
...

In the 1st example one would want to loop through short_paths, then
assign corresponding spth_vals. Just as in any other list,
terms are evaluated left-to-right.

I wondered whether it was worth it keeping the "qqw" terms "simple", or
allow any code option. -- or if something like "xw" would be used
for "executable 'words'", so one could combine a path eval like​:

my ($sysfs, $sys_classes, $netclass, $sys_modules);
my chk_paths=[ XW( $sysfs=/sys $sys_classes=$sysfs/class
  $netclass=$sys_classes/net $sys_modules=$sysfs/module)];
(Xw = liberal "qqw" or Xw=more specific "xw" --- though not sure
of the latter's benefits, off hand).

Anyway, am I just missing this feature, or is it something
that might make sense since on the perlop page, it seems word
list not allowing interpolation begs for a form that would.

Is there any reason wny it would be a good idea?

Perl Info

Flags:
    category=core
    severity=wishlist

Site configuration information for perl 5.16.3:

Configured by law at Wed Jan 22 12:58:58 PST 2014.

Summary of my perl5 (revision 5 version 16 subversion 3) configuration:
   
  Platform:
    osname=linux, osvers=3.12.0-isht-van, archname=x86_64-linux-thread-multi-ld
    uname='linux ishtar 3.12.0-isht-van #1 smp preempt wed nov 13 16:50:51 pst 2013 x86_64 x86_64 x86_64 gnulinux '
    config_args=''
    hint=previous, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=define
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-g -O2',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
    ccversion='', gccversion='4.8.1 20130909 [gcc-4_8-branch revision 202388]', 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='long double', nvsize=16, Off_t='off_t', lseeksize=8
    alignbytes=16, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags ='-g -fstack-protector -fPIC'
    libpth=/usr/lib64 /lib64
    libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc -lgdbm_compat
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    libc=/lib/libc-2.18.so, so=so, useshrplib=true, libperl=libperl-5.16.3.so
    gnulibc_version='2.18'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/home/perl/perl-5.16.3/lib/x86_64-linux-thread-multi-ld/CORE'
    cccdlflags='-fPIC', lddlflags='-shared -g -O2 -fstack-protector -fPIC'

Locally applied patches:
    


@INC for perl 5.16.3:
    /home/law/bin/lib
    /home/perl/perl-5.16.3/lib/site/x86_64-linux-thread-multi-ld
    /home/perl/perl-5.16.3/lib/site
    /home/perl/perl-5.16.3/lib/x86_64-linux-thread-multi-ld
    /home/perl/perl-5.16.3/lib
    .


Environment for perl 5.16.3:
    HOME=/home/law
    LANG=en_US.utf8
    LANGUAGE (unset)
    LC_COLLATE=C
    LC_CTYPE=en_US.UTF-8
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/sbin:.::/home/law/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/sbin:/etc/local/func_lib:/home/law/lib:/home/law/bin/lib
    PERL5OPT=-Mutf8 -CSA -I/home/law/bin/lib
    PERL_BADLANG (unset)
    SHELL=/bin/bash

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 2, 2016

From @mauke

Am 02.03.2016 um 05​:32 schrieb Linda Walsh (via RT)​:

Every once in a while, I start filling an array using
"qw()", when I run into, not too infrequently, a desire
to have a var or expression as a "word". Paths can be
a good example​:

my short_paths=[ qw( sysfs sys_classes netclass sysmods) ];
my spth_vals =[qqw( /sys $sysfs/class $sys_classes/net $sysfs/module ) ];

It's not core perl, but Quote​::Code (available for perl 5.14+) lets you
write this​:

use Quote​::Code;
my $pth_vals = [qcw(
  /sys {$sysfs}/class {$sys_classes}/net {$sysfs}/module
)];

--
Lukas Mai <plokinom@​gmail.com>

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 2, 2016

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

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 2, 2016

From @cpansprout

On Wed Mar 02 00​:03​:42 2016, plokinom@​gmail.com wrote​:

Am 02.03.2016 um 05​:32 schrieb Linda Walsh (via RT)​:

Every once in a while, I start filling an array using
"qw()", when I run into, not too infrequently, a desire
to have a var or expression as a "word". Paths can be
a good example​:

my short_paths=[ qw( sysfs sys_classes netclass
sysmods) ];
my spth_vals =[qqw( /sys $sysfs/class
$sys_classes/net $sysfs/module ) ];

It's not core perl, but Quote​::Code (available for perl 5.14+) lets
you
write this​:

use Quote​::Code;
my $pth_vals = [qcw(
/sys {$sysfs}/class {$sys_classes}/net {$sysfs}/module
)];

Also, if you *know* that your strings contain no wildcards, you can do <foo bar $baz> (or </sys $sysfs/class $sys_classes/net $sysfs/module>), and it won’t even go out to the filesystem, though it is marginally slower than qw and Quote​::Code (at least in theory; I have not measured it).

--

Father Chrysostomos

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 2, 2016

From perl-diddler@tlinx.org

On Wed Mar 02 00​:03​:42 2016, plokinom@​gmail.com wrote​:

It's not core perl, but Quote​::Code (available for perl 5.14+) lets
you
write this​:....


Yeah, I could think of a few ways to do it "manually", but none with the reliability or orthogonal grace of "q"/"qq" => "qw"/"??". It seemed like one of those things that looked like it was missing rather than needing an extension or clever work-workaround.

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 5, 2016

From @rjbs

* Linda Walsh <perlbug-followup@​perl.org> [2016-03-01T23​:32​:14]

Every once in a while, I start filling an array using
"qw()", when I run into, not too infrequently, a desire
to have a var or expression as a "word". Paths can be
a good example​:

  $x = "good job";
  @​y = qqw( $x hunter );

Is @​y now ('good', 'job', 'hunter') or ('good job', 'hunter')? I would think
the latter.

I think that many Perl programmers have wished for qqw at one time or another,
me included.

--
rjbs

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 5, 2016

From @cpansprout

On Sat Mar 05 10​:14​:48 2016, perl.p5p@​rjbs.manxome.org wrote​:

* Linda Walsh <perlbug-followup@​perl.org> [2016-03-01T23​:32​:14]

Every once in a while, I start filling an array using
"qw()", when I run into, not too infrequently, a desire
to have a var or expression as a "word". Paths can be
a good example​:

$x = "good job";
@​y = qqw( $x hunter );

Is @​y now ('good', 'job', 'hunter') or ('good job', 'hunter')? I
would think
the latter.

I would have assumed the former. So I suppose it’s not obvious. BTW, this does the former​:

  $x = "good job";
  @​y = < $x hunter >;

--

Father Chrysostomos

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 5, 2016

From Eirik-Berg.Hanssen@allverden.no

On Sat, Mar 5, 2016 at 8​:06 PM, Father Chrysostomos via RT <
perlbug-followup@​perl.org> wrote​:

$x = "good job";
@​y = qqw( $x hunter );

Is @​y now ('good', 'job', 'hunter') or ('good job', 'hunter')? I
would think
the latter.

I would have assumed the former. So I suppose it’s not obvious. BTW,
this does the former​:

$x = "good job";
@​y = < $x hunter >;

  In Perl6, this does the former, too​:

eirik@​purplehat[22​:25​:34]$ perl6 -e 'my $x = "good job"; my @​y = « $x
hunting »; .say for @​y'
good
job
hunting
eirik@​purplehat[22​:25​:42]
$

  … which surprised me, until I found that this does the latter​:

eirik@​purplehat[22​:27​:52]$ perl6 -e 'my $x = "good job"; my @​y = « "$x"
hunting »; .say for @​y'
good job
hunting
eirik@​purplehat[22​:27​:56]
$

:)

Eirik

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 5, 2016

From @ap

* Father Chrysostomos via RT <perlbug-followup@​perl.org> [2016-03-05 20​:10]​:

On Sat Mar 05 10​:14​:48 2016, perl.p5p@​rjbs.manxome.org wrote​:

$x = "good job";
@​y = qqw( $x hunter );

Is @​y now ('good', 'job', 'hunter') or ('good job', 'hunter')?
I would think the latter.

I would have assumed the former. So I suppose it’s not obvious. BTW,
this does the former​:

$x = "good job";
@​y = < $x hunter >;

I prefer the former. So much so, in fact, that I don’t see any point in
the feature if it does the latter. Because that result is already easy
to achieve in several ways – starting with this very conventional, very
boring, nobody-will-ever-scratch-their-head-about-it approach​:

  @​y = split ' ', "$x hunter";

But a list in which variable values are interpolated yet atomic requires
lots of syntactic ceremony using currently available means​:

  @​subdir = ( "$prefix/foo", "$prefix/bar", "$prefix/baz" );

Consider how much nicer that would be if you got to leave out all those
quotes and separators​:

  @​subdir = qqw( $prefix/foo $prefix/bar $prefix/baz );

A qqw() that splits after interpolating would deprive us of that.

So I think it must work that way or else there’s no point in bothering.

While we’re at it – I would also prefer qqw() to allow comments, and/but
allow backslashing whitespace and octothorpes to demote them from syntax
to string content. Oh, and please – no qw()-style warnings about commas.

Regards,
--
Aristotle Pagaltzis // <http​://plasmasturm.org/>

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 5, 2016

From @ap

* Aristotle Pagaltzis <pagaltzis@​gmx.de> [2016-03-05 23​:00]​:

* Father Chrysostomos via RT <perlbug-followup@​perl.org> [2016-03-05 20​:10]​:

On Sat Mar 05 10​:14​:48 2016, perl.p5p@​rjbs.manxome.org wrote​:

$x = "good job";
@​y = qqw( $x hunter );

Is @​y now ('good', 'job', 'hunter') or ('good job', 'hunter')?
I would think the latter.

I would have assumed the former. So I suppose it’s not obvious. BTW,
this does the former​:

$x = "good job";
@​y = < $x hunter >;

I prefer the former. So much so, in fact, that I don’t see any point in
the feature if it does the latter.

(I meant that I prefer the *latter* – as the rest of the message should
make clear – and that I see the *former* as pointless.)

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 6, 2016

From @kentfredric

On 6 March 2016 at 10​:59, Aristotle Pagaltzis <pagaltzis@​gmx.de> wrote​:

* Father Chrysostomos via RT <perlbug-followup@​perl.org> [2016-03-05 20​:10]​:

On Sat Mar 05 10​:14​:48 2016, perl.p5p@​rjbs.manxome.org wrote​:

$x = "good job";
@​y = qqw( $x hunter );

Is @​y now ('good', 'job', 'hunter') or ('good job', 'hunter')?
I would think the latter.

I would have assumed the former. So I suppose it’s not obvious. BTW,
this does the former​:

$x = "good job";
@​y = < $x hunter >;

I prefer the former. So much so, in fact, that I don’t see any point in
the feature if it does the latter. Because that result is already easy
to achieve in several ways – starting with this very conventional, very
boring, nobody-will-ever-scratch-their-head-about-it approach​:

@&#8203;y = split ' '\, "$x hunter";

But a list in which variable values are interpolated yet atomic requires
lots of syntactic ceremony using currently available means​:

@&#8203;subdir = \( "$prefix/foo"\, "$prefix/bar"\, "$prefix/baz" \);

Consider how much nicer that would be if you got to leave out all those
quotes and separators​:

@&#8203;subdir = qqw\( $prefix/foo $prefix/bar $prefix/baz \);

A qqw() that splits after interpolating would deprive us of that.

So I think it must work that way or else there’s no point in bothering.

While we’re at it – I would also prefer qqw() to allow comments, and/but
allow backslashing whitespace and octothorpes to demote them from syntax
to string content. Oh, and please – no qw()-style warnings about commas.

Regards,

What would this do?​:

$prefix = "/some/path/with a space/";
@​y = qqw{ $prefix/hunter $prefix/bar };

Your description so far indicates that the output would be

( '/some/path/with' , 'a' , 'space/hunter' )

etc.

For clarity, we need a description of the 2 behaviours other than
"former" or "Latter" because backtracking to
work out which one we're talking about is kinda confusing.

expanding-qqw​: variables with spaces in them are interpolated into being lists
preserving-qqw​: variables with spaces in them are treated as
syntactically atomic and indivisible, and any spaces in them are
treated as non-spaces for the purpose of the qqw construct, and only
literal spaces in qqw itself is a separator

--
Kent

KENTNL - https://metacpan.org/author/KENTNL

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 6, 2016

From @ap

* Kent Fredric <kentfredric@​gmail.com> [2016-03-06 06​:20]​:

On 6 March 2016 at 10​:59, Aristotle Pagaltzis <pagaltzis@​gmx.de> wrote​:

[…]

What would this do?​:

$prefix = "/some/path/with a space/";
@​y = qqw{ $prefix/hunter $prefix/bar };

Your description so far indicates that the output would be

( '/some/path/with' , 'a' , 'space/hunter' )

Sorry for the confusion. If you ignore the opening prose and concentrate
on the examples, they will show you what I intended, but since I screwed
that up, let me restate my position for clarity.

This line​:

  qqw( $prefix/foo $prefix/bar $prefix/baz );

… ought to yield the same result as this line​:

  ( "$prefix/foo", "$prefix/bar", "$prefix/baz" );

… and *not* as this line​:

  split ' ', "$prefix/foo $prefix/bar $prefix/baz";

… because that last line is already real easy to write in various ways
that allow low-ceremony syntax for larger lists. E.g. for larger lists,

  split ' ', qq(
  $prefix/foo
  $prefix/bar
  $prefix/baz
  $prefix/quux
  $prefix/qux
  ...
  );

There’s little point in adding yet another way of writing that, when the
other kind of result incurs a per-item punctuation tax​:

  (
  "$prefix/foo",
  "$prefix/bar",
  "$prefix/baz",
  "$prefix/quux",
  "$prefix/qux",
  # ...
  );

(And that’s the least noisy way of formatting it.)

So that is the case that ought to gain some syntactic relief, if any.

Hope I did a better job this time.

Regards,
--
Aristotle Pagaltzis // <http​://plasmasturm.org/>

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 6, 2016

From @kentfredric

On 6 March 2016 at 22​:18, Aristotle Pagaltzis <pagaltzis@​gmx.de> wrote​:

There’s little point in adding yet another way of writing that, when the
other kind of result incurs a per-item punctuation tax​:

\(
    "$prefix/foo"\,
    "$prefix/bar"\,
    "$prefix/baz"\,
    "$prefix/quux"\,
    "$prefix/qux"\,
    \# \.\.\.
\);

(And that’s the least noisy way of formatting it.)

So that is the case that ought to gain some syntactic relief, if any.

Hope I did a better job this time.

Agreed, so we are both proponents of "preserving"-qqw.

preserving-qqw​: variables with spaces in them are treated as
syntactically atomic and indivisible, and any spaces in them are
treated as non-spaces for the purpose of the qqw construct, and only
literal spaces in qqw itself is a separator

The only residual question I have is, what does this do​:

@​x = ('word','word with space');
@​z = qqw( @​x not-touching @​{x}touching );

I assume that the "most obvious" thing would be this to compile the same as​:

@​z = (
  "@​x",
  "not-touching",
  "@​{x}touching",
);

--
Kent

KENTNL - https://metacpan.org/author/KENTNL

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 7, 2016

From @b2gills

I'm going to point out that Perl 6 has a vastly different way of parsing strings
that only looks like the Perl 5 way.

On Sat Mar 05 13​:29​:44 2016, Eirik-Berg.Hanssen@​allverden.no wrote​:

On Sat, Mar 5, 2016 at 8​:06 PM, Father Chrysostomos via RT <
perlbug-followup@​perl.org> wrote​:

$x = "good job";
@​y = qqw( $x hunter );

Is @​y now ('good', 'job', 'hunter') or ('good job', 'hunter')? I
would think
the latter.

I would have assumed the former. So I suppose it’s not obvious. BTW,
this does the former​:

$x = "good job";
@​y = < $x hunter >;

In Perl6, this does the former, too​:

eirik@​purplehat[22​:25​:34]$ perl6 -e 'my $x = "good job"; my @​y = « $x
hunting »; .say for @​y'
good
job
hunting
eirik@​purplehat[22​:25​:42]
$

… which surprised me, until I found that this does the latter​:

eirik@​purplehat[22​:27​:52]$ perl6 -e 'my $x = "good job"; my @​y = « "$x"
hunting »; .say for @​y'
good job
hunting
eirik@​purplehat[22​:27​:56]
$

:)

Eirik

First off `< ... >` is the same as `qw/ ... /`, and `« ... »` is the same as `qqww/ ... /`

Perl 6 starts off with a zero feature quoting mechanism `Q/ ... /` `「 ... 」` then adds features to it
( That is it doesn't even support backslashing the character used for quoting )

Then there is `'...'` `q/.../` `Q​:q/.../` `Q​:single/.../` which enables backslashing backslashes and the quoting character

`​:qq` / `​:double` enables `​:c` / `​:closure`, `​:s` / `​:scalar`, `​:a` / `​:array`, `​:h` / `​:hash`, `​:f` / `​:function`
`​:w` / `​:words` splits on whitespace ( depends on a unicode property )
`​:ww` / `​:quotewords` splits on whitespace, but takes into consideration quotes

Some combinations can be combined without the colons like `qqww/.../` `qx/.../` `qqx/.../`
( basically one base construct `Q`,`q`,`qq` and one other adverb )

There are several other features that can also be enabled like `​:to` for heredocs

Basically `<< ... >>` / `« ... »` is short for
  `qqww /.../`
  `qq :ww /.../`
  `Q :qq :ww /.../`
  `Q :double :quotewords /.../`
  `Q :closure :scalar :array :hash :function :quotewords /.../`
  `Q :closure(True) :scalar(True) :array(True) :hash(True) :function(True) :quotewords(True) /.../`

The spaces between adverbs (feature flags) are optional.

The relevant bit for this discussion​:

  use v6.c;
  my $x = 'Foo Bar';
  say qqww/ $x World /.perl; # ("Foo", "Bar", "World")
  say qqww/ "$x" World /.perl; # ("Foo Bar", "World")
  say qqww/ '$x World' /.perl; # "Foo Bar World"

  # :words not :quotewords
  say qqw/ '$x World' /.perl; # ("'Foo", "Bar", "World'")

  # ignores quotes inside of the embedded string
  $x = "'Foo Bar' Baz";
  say qqww/ $x World /.perl; # ("'Foo", "Bar'", "Baz", "World")

( Again you could use `<< ... >>` or `« ... »` instead of `qqww/.../` )

Perhaps there should be qw// qqw// qww// qqww//

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 11, 2016

From @rjbs

* Aristotle Pagaltzis <pagaltzis@​gmx.de> [2016-03-05T16​:59​:38]

On Sat Mar 05 10​:14​:48 2016, perl.p5p@​rjbs.manxome.org wrote​:

$x = "good job";
@​y = qqw( $x hunter );

Is @​y now ('good', 'job', 'hunter') or ('good job', 'hunter')?
I would think the latter.

I prefer the [latter].

Me, too. Other cases to consider​:

  @​x = qqw( abc @​def ghi );

...which would need to have three elements, to match this​:

  @​x = qqw( x​:abc x​:@​def x​:ghi );

It would be bizarre for the second example to only have x​: on the first element
from @​def. If @​def is empty, it ought to become "", similarly.

Someone will probably have to stop and think about​:

  @​x = qqw(
  abc
  $def->{ ... ... ... }
  ghi
  );

...because of the spaces in the expr in the second element. I think this is
okay.

While we’re at it – I would also prefer qqw() to allow comments, and/but
allow backslashing whitespace and octothorpes to demote them from syntax
to string content.

Agreed.

Oh, and please – no qw()-style warnings about commas.

I have no feelings on this.

--
rjbs

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 11, 2016

From @cpansprout

On Thu Mar 10 16​:01​:19 2016, perl.p5p@​rjbs.manxome.org wrote​:

* Aristotle Pagaltzis <pagaltzis@​gmx.de> [2016-03-05T16​:59​:38]

On Sat Mar 05 10​:14​:48 2016, perl.p5p@​rjbs.manxome.org wrote​:

$x = "good job";
@​y = qqw( $x hunter );

Is @​y now ('good', 'job', 'hunter') or ('good job', 'hunter')?
I would think the latter.

I prefer the [latter].

Me, too. Other cases to consider​:

@​x = qqw( abc @​def ghi );

...which would need to have three elements, to match this​:

@​x = qqw( x​:abc x​:@​def x​:ghi );

It would be bizarre for the second example to only have x​: on the
first element
from @​def. If @​def is empty, it ought to become "", similarly.

Would you please clarify with examples? Does x​:@​def above become one element of @​x, or does it fill @​x with as many elements as are in @​def?

Someone will probably have to stop and think about​:

@​x = qqw(
abc
$def->{ ... ... ... }
ghi
);

...because of the spaces in the expr in the second element. I think
this is
okay.

You just switch to a different parsing style when you encounter the $. Standard double-quote parsing solves it that way.

<wishful thinking>

That said, I wish we could solve this kind of nonsense​:

  qq<$x{">"}>; # syntax error

If strings were parsed just like blocks of code, there would be no reason for that not to work. After all, { "}" } and ["]"] work. As it is, the final delimiter of the string is searched for before the body is parsed. It has to be that way for quote-like operators with flags at the end.

It would have been saner if the parsing had been done the other way round from day 1 (with the flags in some other spot).

Would it be possible to make qqw work the ‘new’ way? Or would it be to confusing if it does not conform to the way qw works?

</wishful>

While we’re at it – I would also prefer qqw() to allow comments,
and/but
allow backslashing whitespace and octothorpes to demote them from
syntax
to string content.

Agreed.

Oh, and please – no qw()-style warnings about commas.

I have no feelings on this.

That is one of the most annoying warnings. If it warned *only* when all the elements are comma-separated, it would be helpful for new bees without annoying people trying to do this​: qw( . , ; : ) etc. Currently, just *one* comma anywhere in the qw will raise the warning.

If we could restrict the warning that way, I would not mind it on qqw. It might be good to apply the restriction to qw as well.

--

Father Chrysostomos

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 11, 2016

From @rjbs

* Father Chrysostomos via RT <perlbug-followup@​perl.org> [2016-03-11T00​:52​:04]

On Thu Mar 10 16​:01​:19 2016, perl.p5p@​rjbs.manxome.org wrote​:

@​x = qqw( x​:abc x​:@​def x​:ghi );

It would be bizarre for the second example to only have x​: on the first
element from @​def. If @​def is empty, it ought to become "", similarly.

Would you please clarify with examples? Does x​:@​def above become one element
of @​x, or does it fill @​x with as many elements as are in @​def?

I mean that, given @​def=(1,2,3), @​x would be​:

  ("x​:abc", "x​:1 2 3", "x​:ghi")

That said, I wish we could solve this kind of nonsense​:

qq<$x{">"}>; # syntax error
[...]
Would it be possible to make qqw work the ‘new’ way? Or would it be to
confusing if it does not conform to the way qw works?

I think it would be too confusing. :(

--
rjbs

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 23, 2016

From @Abigail

On Thu, Mar 10, 2016 at 07​:00​:53PM -0500, Ricardo Signes wrote​:

* Aristotle Pagaltzis <pagaltzis@​gmx.de> [2016-03-05T16​:59​:38]

On Sat Mar 05 10​:14​:48 2016, perl.p5p@​rjbs.manxome.org wrote​:

$x = "good job";
@​y = qqw( $x hunter );

Is @​y now ('good', 'job', 'hunter') or ('good job', 'hunter')?
I would think the latter.

I prefer the [latter].

Me, too.

Do we have to make a choice? If someone is going through the
trouble of implementing qqw() (or something similar named),
why not introduce two constructs, one for each option?
Then the user can use whatever he/she needs.

Abigail

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 23, 2016

From @ap

* Abigail <abigail@​abigail.be> [2016-03-23 18​:50]​:

On Thu, Mar 10, 2016 at 07​:00​:53PM -0500, Ricardo Signes wrote​:

* Aristotle Pagaltzis <pagaltzis@​gmx.de> [2016-03-05T16​:59​:38]

On Sat Mar 05 10​:14​:48 2016, perl.p5p@​rjbs.manxome.org wrote​:

$x = "good job";
@​y = qqw( $x hunter );

Is @​y now ('good', 'job', 'hunter') or ('good job', 'hunter')?
I would think the latter.

I prefer the [latter].

Me, too.

Do we have to make a choice? If someone is going through the trouble
of implementing qqw() (or something similar named), why not introduce
two constructs, one for each option? Then the user can use whatever
he/she needs.

IMO the other option already has an existing construct​:

  split ' ', qq( ... )

Do you consider that not good enough for some reason?

Regards,
--
Aristotle Pagaltzis // <http​://plasmasturm.org/>

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Mar 23, 2016

From @Abigail

On Wed, Mar 23, 2016 at 09​:22​:08PM +0100, Aristotle Pagaltzis wrote​:

* Abigail <abigail@​abigail.be> [2016-03-23 18​:50]​:

On Thu, Mar 10, 2016 at 07​:00​:53PM -0500, Ricardo Signes wrote​:

* Aristotle Pagaltzis <pagaltzis@​gmx.de> [2016-03-05T16​:59​:38]

On Sat Mar 05 10​:14​:48 2016, perl.p5p@​rjbs.manxome.org wrote​:

$x = "good job";
@​y = qqw( $x hunter );

Is @​y now ('good', 'job', 'hunter') or ('good job', 'hunter')?
I would think the latter.

I prefer the [latter].

Me, too.

Do we have to make a choice? If someone is going through the trouble
of implementing qqw() (or something similar named), why not introduce
two constructs, one for each option? Then the user can use whatever
he/she needs.

IMO the other option already has an existing construct​:

split ' '\, qq\( \.\.\. \)

Do you consider that not good enough for some reason?

First of all, I don't have a strong need for qqw, regardless of what
meaning is given to it. But I can see some value in either of the
discussed meanings. I just want to point out there's also the possibility
to add more than one construct.

As for the "but here's a way to do it" argument, I don't find that a
very convincing argument.

qw can be expressed as

  split ' ', q (...)

but does that mean qw() is a waste?

Also, the variant you favour can also be easily expressed otherwise​:

  @​y = ($x, "hunter");

so that would argue to not implement qqw at all.

Nor 99% of the other features which are being proposed.

Abigail

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 15, 2017

From zefram@fysh.org

The proposed qqw() should be implemented on CPAN first. If experience
with that shows it to be popular, then we could consider adopting it into
the core. There's no justification here for implementing it in the core
without seeing such a prototype first. This ticket should be closed.

-zefram

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 21, 2017

From @xsawyerx

On Thu, 14 Dec 2017 23​:13​:43 -0800, zefram@​fysh.org wrote​:

The proposed qqw() should be implemented on CPAN first. If experience
with that shows it to be popular, then we could consider adopting it into
the core. There's no justification here for implementing it in the core
without seeing such a prototype first. This ticket should be closed.

Agreed.

Examples of other examples​:

https://metacpan.org/pod/Quote::Code
https://metacpan.org/pod/Quote::Ref

@p5pRT
Copy link
Author

@p5pRT p5pRT commented Dec 21, 2017

@xsawyerx - Status changed from 'open' to 'rejected'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant