Arjen Markus I was inspired by a book on software architecture (Mary Shaw and David Garlan: Software Architecture, perspectives on an emerging discipline) to start thinking about implementing "pipelines" in Tcl. Consider the following example: we want to remove all comment lines from a C source file. One way to do this, is to read in the file, filter out those lines and pieces of text that belong to a comment and write out the remainder.In one line:
output [nocomments [readfile $input_name]] $output_nameOr:
set content [readfile $input_name] set filtered_content [nocomments $content] output $filtered_content $output_nameSo, you get a more or less complicated chain of commands, the one taking the output from the previous one.The drawbacks of this approach are:
- You need to keep the whole file in memory and possibly one or more processed copies.
- You need to wait for the whole file to be read or processed before the next step can proceed.
set infile [open "$input_name" "r"]
set outfile [open "$output_name" "w"]
while {[readline $infile line] >= 0 } {
set filtered_line [nocomments $line]
outputline $filtered_line $outfile
}
close $infile
close $outfileWell, this solves the first objection to the previous method, but the second is changed into:- You need to wait for output to become available, if the input file is the output from a separate process or a socket
- How do you handle the case where [nocomments] filters out the entire line? This requires additional logic, probably in the outer loop.
- What if one line of input causes multiple lines of output from [nocomments] (or some other command, say a pretty printer)?
RS still wonders how this differs from Streams à la SICP...Lars H: Or how this relates to bwise.TV (Long ago maker of Bwise, inspired by Khoros and Avs and schematic diagrams (I'm Uni EE)) Thank you! The answer is: take Hoare and Milner, check out the long-existing original (? for me anyhow) AT&T and Berkeley versions of Unix from the 70s (depending on what you want, some things from the 80s) and you suddenly know most fundamentals of practical and theoretical flow based programming. Of course your concept terminology milage may vary, flow isn't usually meant the same as stream, parallelism isn't the same as multiprocessing, etc...
