On Thu, Aug 01, 2013 at 09:15:24PM -0400, Simon Spero wrote: > If your code is not lazy then you're being too strict :-) ;) > If you're using ghc, you can use the "-ddump-stranal" to see what > expressions the compiler is identifying as strict; I thank you for your explainations: I'll do when i'll have time but i think i know my error: i thought readfile is lazy, it's not :) > Also, does what parts of ISO2709 does French MARC use that is not > compatible with Z39.2; As far as I know, all MARC files i have seen was valid iso2709 ones (and when they are not, authors admited they are not). > likewise, are characters encoded in real 5426, > or in the MARC-8 simulacrum thereof? haha... good question: i guess it is but i have found some differences between implementations and tables i rely on and i admit i didn't have an official document to validate my current work: https://github.com/eiro/p5-encode-iso5426/blob/master/iso-5426.ucm > Get back to language non-wars; lazy parsing of marc can be a big win, even > in eager languages ... > some miracle the length at the start of the record happens to be correct, > there is no immediate need to parse the contents of the record. this is an exemple of MARC::MIR / Perlude cooperation to do that: # show every IDs of records that contains the string "test" # as the from_iso2709 is the parser itself, nothing is parsed # when the record doesn't contain "test" sub report_id { any_fields { tag eq '001' && say value } from_iso2709 } now { report_id if /test/ } iso2709_records_of "biblio.marc"; iso2709_records_of is a generator on serialized records from_iso2709 deserialize to a MARC::MIR any_fields execute the block on all fields while not true tag and value are self explained :) It's lazy *and* very simple to write. In general, MARC::MIR is way faster than every other implementations but i really think having something like go channels and haskell concurrency could make a new gap. thanks for help marc