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

[Permjacov Evgeniy]

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 <permeakra at gmail.com> 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 <permeakra at gmail.com> 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 at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>>
>>