Nicholas Ingolia <n...@ingolia.org> writes: > After some discussion on this list, I used a newtype-wrapped Int64, > rather than a type-aliased Int64, for offsets in my seqloc > library. With a fair bit of experience writing code against this > interface, I can say that it works well--the Num instance supplies > everything you need for arithmatic and literals. Would this definition > of Offset work for biocore? Client code would just need fromIntegral > added in a few places, and these would actually be optimized away.
Sorry about the late reply! Currently, the following definitions occur in Bio.Core.Sequence: type SeqData = LC.ByteString -- ^ Sequence data are lazy bytestrings of ASCII characters. type Qual = Word8 -- ^ A quality value is in the range 0..255. type QualData = L.ByteString -- ^ Quality data are lazy bytestrings of 'Qual's. type Offset = Int64 -- ^ An 'Offset' is a zero-based index into a sequence I guess they could all easily be newtypes instead, although I'm not sure what the impact would be. Instances like Num and IsString might alleviate things a bit. I'd like to be able to still provide the old 'bio' library, but using imports from the new libraries. Currently, I'm just re-exporting these definitions, which a lot of code depends on, so I think this will be harder. But perhaps I can sacrifice backwards compatibility here? -k -- If I haven't seen further, it is by standing in the footprints of giants _______________________________________________ Biohaskell mailing list Biohaskell@biohaskell.org http://malde.org/cgi-bin/mailman/listinfo/biohaskell
