Re: Pipe dream

[Roy Johnson]

As you mention, it should be do-able with iterators rather than requiring interprocess pipes. Some idle doodling came up with a syntax that appeals to me and might appeal to you.

  # chain_lines takes a list of coderefs
  # The first sub in the chain is called with no input; subsequent one
+s are called
  # with $_ set to the line from the previous sub; the iterator return
+s one line of
  # output from the last sub in the chain. If a sub yields undef, proc
+essing
  # restarts at the first sub. When the first sub yields undef, the it
+erator is done.
  my $i = chain_lines sub { <$in> },
                      sub { /^42/ ? $_ : undef },    # grep
                      sub { join "\t", (split /\t/)[1,3,8] };
  # all_lines expands the iterator into a list of lines
  sort all_lines($i);

The grep case might warrant its own special syntax, like

grep_lines {/^42/}

[diotalevi]

If you're going to write a grep iterator, have the return value be an empty list on element failure. This allows failures to be removed from the list instead of just being substituted with undefined values. In fact, grep is just a special case of map.

grep /^42/
map { /^42/ ? $_ : () }
sub { /^42/ ? $_ : () }

[Roy Johnson]

undef is a special value in the scheme I've proposed. All results are taken in scalar context (assigned to $_), since this is a line-piping scheme. If the grep step returns undef, the iterator goes back to the first sub to try a new line. undefs do not show up in the output stream.

You could use an empty list as your no-line-returned indicator, but it would require you evaluating the subs in list context and then turning the returned value into a scalar afterward. That would be problematic for some common pipe actions, like reading one line at a time from a file (in list context, the whole file would be read).

[diotalevi]

Oh. I don't normally privilege undef that way. Its another value, just like other values.