additional Int53 api using Number #37

[grmble]

This would be one suggestion.

• additional API so existing code won't break
• no additional dependencies (i.e. using Number instead of Data.Int53
• not entirely happy with fdReadInt53/fdWriteInt53 when using Number. fdReadLarge?

[hdgarrood]

Yeah, as it happens I’ve never liked the “int53” name, as to me that name ought to imply proper twos-complement ints with 53 bits, not floats which happen to behave like integers as long as you stay below 2^53. I think Number is indeed the right choice here.

I think the type synonym is also a bit misleading though, it would be better to just use Number.

A “large” suffix to differentiate these from the normal versions sounds sensible to me.

[hdgarrood]

Rather than having two copies of the implementation for each function, though, I’d rather just import each once and implement the old ones in terms of the new ones.

[grmble]

How about this version?

I made all the arguments Number this time. If you use this API, you will probably do some math with positions and byte counts. It's easier to use if everything is the same type.

I just noticed Atom reformatted all the changed import lines. Will fix that in the next round

[grmble]

Thinking about this some more, it would probably be better to leave everything except the file position an Int. You might have to add the byte count to your position, but Int -> Number is easy. Number -> Int is the troublesome part, and if you need to calculate buffer offsets you need an Int.

[grmble]

No idea what the travis problem is. I just tried the exact commands from the travis config

[grmble]

Ah! Travis is having issues. https://www.traviscistatus.com/

I'll trigger a rebuild once Travis service continues