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:

> 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";

    is a generator on serialized records

    deserialize to a MARC::MIR

    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