[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Possible Lua enhancements 2: Piping
- From: Mark Hamburg <mark@...>
- Date: Thu, 18 Dec 2008 11:10:32 -0800
On Dec 18, 2008, at 9:36 AM, Luiz Henrique de Figueiredo wrote:
pipe(producer(), filter1, filter2, ..., consumer)
That won't work if the producer can generate multiple values and we
need to pass those along.
How about
pipe(producer, filter1, filter2, ..., consumer) (args-to-producer)
That seems workable. It's a bit of a pain from a clarity standpoint to
split the producer from its arguments, but at least it keeps the pipe
presentation clear.
Order of evaluation remains a bit less than ideal, but most of the
cases where that would matter are probably suspect anyway.
for k, v in pipe( pairs, filter_key_type( "string" ) ) do
-- process pairs with key type string
end
Or in my original example:
for obj in pipe( io.lines, chunk_lines( "----------" ),
chunk_to_object )( "objectlist.dat" ) do
-- process objects from file
end
This also has the benefit of encouraging one to define:
iterate_objects_from_file = pipe( io.lines,
chunk_lines( "----------" ), chunk_to_object )
So, it is probably more in keeping with Lua's general style.
One could also extend .. to support pipe construction yielding:
for obj in ( io.lines .. chunk_lines( "-----------" ) ..
chunk_to_object )( "objectlist.dat" ) do
-- process objects from file
end
The difference between this and my original piping proposal is
basically some extra parentheses and the separation of the arguments
to feed the pipe from the head of the pipe.
And, of course, pipe is now essentially reverse function composition
which might itself make a play for the .. operator.
Since my initial impetus was driven by LINQ, I should go back and look
at some of the standard LINQ examples to see how they would look.
Mark
P.S. pipe is probably a lot easier to write in C rather than Lua since
it needs to do a lot of manipulation of multiple values as it passes
all of the results from one function to the next function. It would be
nice to improve that situation, but that's a whole different topic.