On Thu, Dec 9, 2010 at 10:32 PM, Permjacov Evgeniy wrote:

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.

For the record, enumerator (and I believe iteratee as well) uses transformers, not mtl. transformers itself is Haskell98; all FunDep code is separated out to monads-fd. Michael

...

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

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

John Millikin schrieb:

On Thu, Dec 9, 2010 at 12:43, Michael Snoyman wrote:

...

For the record, enumerator (and I believe iteratee as well) uses transformers, not mtl. transformers itself is Haskell98; all FunDep code is separated out to monads-fd.

Michael

iteratee also uses 'transformers', but requires several extensions; see < http://hackage.haskell.org/packages/archive/iteratee/0.6.0.1/doc/html/src/Da...

It seems silly to avoid extensions, though; every non-trivial package on Hackage depends on them, either directly or via a dependency. For example, though 'enumerator' requires no extensions itself, it depends on both 'text' and 'bytestring', which require a ton of them.

It's not silly. If you want to use other compilers like JHC, you are lucky if the used packages are simply Haskell 98. Haskell 98 is already complicated enough. I am often very annoyed if a package imports only a simple utility function from another package that in turn depends on multiple packages that in the end require all available GHC extensions. Also using a GHC extension is often the consequence of a design flaw. E.g. (instance C String where) is possible, but the Haskell 98 solutions to it are usually cleaner. My slogan is: Solve simple problems the simple way. Most of my packages are Haskell 98. http://www.haskell.org/haskellwiki/Use_of_language_extensions