Re: [Haskell-cafe] A home-brew iteration-alike library: some extension quiestions

On 12/09/2010 11:17 PM, Antoine Latter wrote:

Also, one thing that tripped me up is that your "Stream" type is fundamentally different from the "Stream" types in the iteratee/enumerator libraries - yours is more of a monadic list in the inner monad, with explicit errors.

How does this change the operation of the Iterator type? The problem was that I wished Zippee. It means that external enumerator must be "suspended" at some points so Zippee can process elements from both left and right streams in desired order. It makes any other approach I considered impossible to use.

Also, in what way are the other libraries not Haskell-2010 compliant? I haven't experimented too much with this sort of thing, since Cabal defaults to the Haskell '98 language, and that's how I install most things. Haskell-2010 does not include functional dependencies (wich are considered evil by many) and, as I recall, type families. This makes mtl haskell-2010 and haskell-98 uncompilant -(. Functional dependencies and type familes are tricky things, so it is better to avoid them. Thanks for your response, Antoine

On Thu, Dec 9, 2010 at 2:07 PM, Permjacov Evgeniy wrote:

...

On 12/09/2010 10:54 PM, Antoine Latter wrote:

...

I only have some surface level questions/comments -

What existing packages is this similar to? How is it different from any previous work in the area?

Main idea was taken from Iteratees invented by Oleg Kiselev (there are two packages on hackage implementing this ideas: data-iteraties and enumerator packages) The difference is, that I wished haskell-2010 compilant package for left-foldable streams, including support for easy builing, transcoding, merging and folding of streams relying on do-notation (see Data.Iteration.Unicode.* for examples of transcoding streams: it is quite clean and easily understandable) and ability to specify easily monadic actions in stream processors.

...

Also, likes looks like you don't need the 'Monad m' constraint on your various Monad and Functor instances in Data.Iteration.Types, which I think is one of the nicest properties of the continuation-based approach to something like this. Errgh. That may be true, but I did not consider non-monadic context at all, so I enforced this constrain mindlessly It's a mater of taste which way to go, but I prefer importing modules qualified rather than have type-suffixes on functions - so I would rather use 'I.next' and 'A.next' instead of 'nextI' and 'nextA'. But reasonable people can disagree on this.

Take care, Antoine Thanks! On Thu, Dec 9, 2010 at 1:42 PM, Permjacov Evgeniy wrote:

...

Hi. I Wrote a simple iteration library. It was not intensively tested, so it MAY contatin bugs, but it is very unlikely. The library is currently on github: https://github.com/permeakra/iteration

I'm not ready to upload it to hackage, as some testing and extension is really needed. However, I'd like to know about possible flaws.

Current goal is addition of byte-stream (de)compression and IO functions extenstion. After this package will be cabalized and uploaded to hackage. So, while design is not frozen yet, I'm interested in criticism -)/

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe