dagit: > As the top search result. > > This means that you can convert any list of maybes into a list of what you > want. It just tosses out the Nothings. > > 2. Why doesn't ByteString implement 'read'? Is it just that this > function (like 'input' in Python) isn't really very useful for real > programs? > > I think probably for things more complex than parsing ints it's best to > make your own parser? I seem to recall that someone was working on a > library of parsing functions based on bytestring? Maybe someone else can > comment? > > 3. Why doesn't ByteString implement 'readDouble', etc.? That is, why > are Int and Integer treated specially? Do I not need readDouble? > > I think readInt was mostly implemented because integer reading was needed > a lot for benchmarks and programming challenge sites and people noticed it > was way slower than needed so someone put in the effort it optimize it. > Once it was optimized, that must have satisfied the need for fast number > reading.
There's readInt, readInteger and readDouble now, as primitives, because people ask for them. > I would agree that at least for Prelude types it would be nice to have > efficient bytestring based parsers. Do we have Read/Show classes > specifically for working in bytestrings? Maybe that's what the world > needs in the bytestring api. Then again, I'm not really qualified to > comment :) For all I know it already exists. > Data.Binary is the generic parser for bytestrings. A higher level one for parsing text (e.g. atto-parsec), might be worthwhile. -- Don _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
