On Tuesday July 17 2012 12:37:00 PM Dave Mitchell wrote: > On Sat, Jul 14, 2012 at 10:00:18PM -0600, Darin McBride wrote: > > a) The todo is backwards: it looks like qx is the function behind readpipe > > :-) However, since I don't think we want to complicate qx to take a list > > (I think that "qwx( some list here)" would be of limited use without > > interpolation, and qw doesn't interpolate, so I expect it to get messy > > just from a UX perspective), what this todo effectively means is that qx > > is now a subset of readpipe. So I'm thinking that a first foray here > > might be to just switch the implementation around such that we have a > > "readpipe" op that is distinct from qx, and then have qx call the > > readpipe op. This should not affect any tests. > Er, qx// is already a subset of readpipe; > i.e. qx/foo/ is just short for readpipe qq/foo/, while readpipe can take a > general argument, such as readpipe foo(1); > They both resolve to the OP_BACKTICK op, implemented by Perl_pp_backtick(). They both resolve to backticks ;-) The fact that readpipe lets the rest of the parser deal with how it gets its string doesn't seem to change much from what I'm looking at. readpipe foo(1) vs `@{[foo(1)]}` It's not like OP_BACKTICK has to handle either of these - they're resolved before Perl_pp_backtick ever gets called. Maybe from what you're saying I can "just" look at changing readpipe's prototype and then dealing with it in Perl_pp_backtick. My head is already swimming :-D Thanks,Thread Previous | Thread Next