I have found a unique advantage of Clojure, and perhaps most functional programming languages. As you design and test your Clojure program, the code can become simpler if tasks, for example like filtering bad input data, are handled further upstream. Because many Python packages tend to return data in list/tuple form, I found the same thing in Python, but the nature of Clojure seems to enforce this better.
Here is an example of bad input data.
1,27 LILLIAN RD, ,E HAMPSTEAD HEATH, OC, ,11,9999899999,e,
This represents a code for the web application (1), first and second street addresses. (The second street address is null, city and state, followed by year, bill number, and account type. The trailing ‘,’ delimiter is supposed to be there.
The seventh position in, right after city (OC) is blank. For some reason the web application returns no zip or zip+4 in this instance even though the [real] address is valid. Therefore, we need to filter the input data early in the program.
Using other languages, you could solve this problem almost anywhere, and I’m not sure that is always a good thing.
When the input file (csv) returns from the call to clojure-csv/parse-csv, it is then filtered to make sure zip is not blank. Otherwise, the address can not be barcoded unless the zip-code data is present.
(defn gen-parsed-csv-file "Returns a sequence generated by parse-csv" [file-name] (let [ data (slurp file-name) inter-csv-rows (parse-csv data) all-csv-rows (vec (filter #(and (pos? (count %)) (not (cstr/blank? (nth % 5 nil)))) inter-csv-rows))] all-csv-rows))