[darcs-devel] [patch1680] five Bytestring-related patches from Ben's branch

[Ben Franksen]

Ben Franksen <ben.franksen at online.de> added the comment:

> Why not use (BC.singleton '\n') instead of (BC.pack "\n")?

No particular reason I can think of.

> # refactor, simplify, and document hunk application
> This is a heavy one.

Indeed. The code is subtle I needed quite a while to understand it. It
is still not as clear as I would like it to be.

One of the conclusions I took away from this refactor is that FileUUID
does the right thing here: its hunks aren't line based any more, a hunk
takes out a slice of the content and replaces it with another one. This
means apply is trivial and the complexities of how we interpret the data
as "lines" is moved out of the core and into the user interface.

> linesPS definition is changed...

I must say I can't remember why I was thinking this is an improvement.
It looks like a mistake to me now. The previous definition is more
concise and I see no reason why it should be less efficient. Please roll
it back. And thanks for spotting it.

I was probably confusing this with the change to unlinesPS which really
is an improvement (for the reason you guessed).

This has nothing to do with a18PerformIO. I think we have no choice but
to trust the regular ByteString API is safe to use, whatever dirty
tricks the implementation might use. But the Internal API is really
extremely dangerous (indeed much more so than C programming since you
have to take things like the GC and lazy evaluation into account).

__________________________________
Darcs bug tracker <bugs at darcs.net>
<http://bugs.darcs.net/patch1680>
__________________________________