Byte stream types shouldn't have much advantage over regular lazy bytestring here since aeson `decode`, which is defined using `Attoparsec.parse` will be the more expensive calculation, and of course it accumulates whatever it needs, validating the input before returning an answer. So there's not much point in giving it a proper streaming io input.
The json-stream library does permit you to stream values as they arise, /if/ all the pieces fit together. http://hackage.haskell.org/package/json-stream-0.4.1.0/docs/Data-JsonStream-Parser.html This is really only convenient if for example the top level json value is an array. I wrote a little helper for this, maybe you saw https://hackage.haskell.org/package/streaming-utils-0.1.4.3/docs/Data-ByteString-Streaming-Aeson.html#v:streamParse The program at the top of the file uses it. But it all depends on the structure of the json and what you are hoping to get from it. It is also simple to stream the elements of a one subordinate array of a top level object, or to stream all the elements of all the subordinate arrays of a top level array, forgetting anything else about the element of the array these elements came from (I think that's the case in my example, if I remember). But trying to get more complex structure would require designing an appropriate free monad for each case. (Maybe that's not so crazy though) It isn't clear that something like `json-stream` doesn't violate the whole idea of json, which envisages validation of the whole file as a condition of parsing. The decision that named fields in an 'object' can come in any order and can be missing and so on, is a mess from a number of points of view, one of them being proper streaming. -- You received this message because you are subscribed to the Google Groups "Haskell Pipes" group. To unsubscribe from this group and stop receiving emails from it, send an email to haskell-pipes+unsubscr...@googlegroups.com. To post to this group, send email to haskell-pipes@googlegroups.com.
