polyparse

[Tony Morris]

I think we should merge in Gerolf Seitz' port of polyparse. Comment?

--
Tony Morris
http://tmorris.net/

[Gerolf Seitz]

Couple of points:

* there's no documentation in there at all

* still no tests

* what I don't like is that the lazy parser wraps the strict parser (they only differ in the implementation of `ap`), but that may be solved by value classes in the future?

* I also think that the laziness is not correct everywhere (haven't checked/verified that yet)

* Still needs some polishing

I wouldn't merge it yet into scalaz-seven, but if anyone wants to help out we can move the branch to the scalaz repo.

--
You received this message because you are subscribed to the Google Groups "scalaz" group.
To post to this group, send email to sca...@googlegroups.com.
To unsubscribe from this group, send email to scalaz+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scalaz?hl=en.

--

Gerolf Seitz

twitter: @gersei

code: github.com/gseitz

blog: www.gerolfseitz.com

[Tony Morris]

On May 18, 2012 4:02 PM, "Gerolf Seitz" <gerolf...@gmail.com> wrote:
>
> Couple of points:
>
> * there's no documentation in there at all
> * still no tests
> * what I don't like is that the lazy parser wraps the strict parser (they only differ in the implementation of `ap`), but that may be solved by value classes in the future?
> * I also think that the laziness is not correct everywhere (haven't checked/verified that yet)
> * Still needs some polishing
>
> I wouldn't merge it yet into scalaz-seven, but if anyone wants to help out we can move the branch to the scalaz repo.

I moved the scalaz-seven-parse branch to the main repository.

[Gerolf Seitz]

Okay, maybe rename/repush as "topic/parse", to start the tradition of a tidy repository? ;)

[Jason Zaugg]

I would keep it as a separate project (could be under the scalaz
github account, if you like). Our release cycle for Scalaz is pretty
slow -- do you want to limit yourself to that?

-jason

[Lars Hupel]

> I would keep it as a separate project (could be under the scalaz
> github account, if you like). Our release cycle for Scalaz is pretty
> slow -- do you want to limit yourself to that?

I share Jason's objections. The project seems as a good fit for a
seperate repository because it would be independent from the main
releases. Also, maintenance would be easier.

[Runar Bjarnason]

I agree, keep it as a separate project. I use a number of different parsers myself, all depending on Scalaz. So I wouldn't want to commit to having one of them as part of the main project.

Runar

[Tony Morris]

I submit polyparse specifically as a general purpose parsing library, not too different to parsec in purpose, modulo the try combinator. I would like a scalaz.parse module for thus purpose.

I don't quite understand the pushback, when similar distinctions can be made for other scalaz modules. Nothing about scalaz.parse ties it to a single parser model.

Have you used the built-in scala parsers by any chance?

[Runar Bjarnason]

Pushing back for the same reason that I wish scalaz.iteratee did not exist. It should be a separate library.

Runar

[Tony Morris]

What difference does it make as a separate library?

[Runar Bjarnason]

Then I don't have to maintain it.