On Tue, Jul 30, 2013 at 11:07 AM, Marc Chantreux <[log in to unmask]> wrote:

> On Tue, Jul 30, 2013 at 10:27:01AM -0400, Mark A. Matienzo wrote:
> > i don't know why we're not talking about Haskell
>
> I did to tell there is a lack of libraries and it is not as convenient
> as perl when it comes to use regexps.
>
> I wrote a MARC::MIR reader for ISO2709 but have some issues (it seems it
> is not lazy as expected) and need IS05426 support.
>

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; since the goal of doing
this analysis is to propagate this information as far as possible to reduce
cons up suspensions as much as possible, it might be hard to figure out
where the root of the contagion is coming from.

If you separate the purely functional parts of the code from the code that
is messing around with monads it should be easier to figure out where
things are getting forced unexpectedly.

Also, does what parts of ISO2709 does French MARC use that is not
compatible with  Z39.2; likewise, are characters encoded in real 5426, or
in the MARC-8 simulacrum thereof?

Get back to language non-wars;  lazy parsing of marc can be a big win, even
in eager languages.  Once you know that you've read a whole record (e.g. by
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.  If you
need the leader, you can parse it when you need it;  if you need tags, you
can start parsing directory entries ; if you need fields, you can use the
directory info, and if you need subfields, you can find the subfield
markers.

 If you're lucky, you can avoid a lot of first and second cache pollution.
 Also, if you're using multiple cores, and even more so, multiple
processors, you may be able to avoid sharing the whole of a record across
caches.

Simon