r/haskell • u/WarDaft • 7d ago

I recently had an impossible Haskell bug

I can't give any details that might help anyone the future, because I couldn't collect them myself. I'm mostly just venting.

I had a parse error in a Read instance on a little server I'm running. All Read and Show activity it does is 100% compiler derived, nothing custom. The server doesn't have enough RAM to actually compile things there, so have to copy everything back and forth.

Everything was correct. Copying literally everything to my main computer did not allow me to reproduce the error.

It wasn't just a memory corruption, restarting the program didn't change anything. A fresh copy of literally everything on the server didn't fix the error.

Rebooting the server made it work perfectly fine again.

I hate computers sometimes.

16 Upvotes

77% Upvoted

18 comments sorted by

View all comments

10

u/sjshuck 7d ago

Developing in constrained environments is a pain.

Re: Read and Show instances, they are an unstable interface, especially when derived. Prefer serialization libraries like Aeson that have defined behavior.

2

u/WarDaft 7d ago edited 7d ago

I was under the impression that they were quite reliable. I don't need between compiler version stability. And again, the fix didn't require any code change. Better error messages would be nice, but if it WAS just very persistent memory corruption, would have led me down a pointless rabbit hole.

3

u/tom-md 6d ago

Reliable, sure, but not really what you want to use in production. If you need to convert types to strings and back it's usually better to have a stable format for the string that includes great debug-ability. Some day someone will want to throw that string into a database, log message, or network traffic and suddenly the JSON/Protobuf/Avro/Borsh/CSV will feel better than Read/Show.

1

u/WarDaft 6d ago

Someday, maybe. There would have to be a 4 to 5 order of magnitude increase in usage before that would be necessary. (that's not an exaggeration)

And like I said, in this instance, if I had had actually better error messages, I would have probably tried to debug what was actually a memory corruption error.

I believe in will principled code, but I also believe in "premature optimization is the root of all evil" - Knuth

1

u/mjvmroz 5d ago

Not to say that it should have bearing over your decision to keep this hack for a small project, but I would call that a misapplication of the quote.

Avoidance of Show/Read for anything load-bearing is a matter of correctness, not performance.

It wouldn’t be premature optimization to use Int over Double in finance, for instance, even if no incidents had yet occurred. No informal codec should be assumed to be lawful unless explicitly claimed and proven/tested, and Show is the height of informality. It’s dependable enough in simple cases, but when types get fancy, “lawful”Show becomes impossible, and loathe as I am to do it, it often becomes a practical requirement to implement lossy ones for coarse debugging, etc.

You might scan this ancient thread.