Make sepEndBy stack safe

[hjmtql]

I encountered stack overflow when I used sepEndBy for large data.
It seemed to be caused by sepEndBy and sepEndBy1 are calling each other.
So I added a test and fixed sepEndBy1 using stack safe many.

It seems that chainl and chainr should also be fixed.
However I fixed only sepEndBy with this PR because these functions are a little complicated to me.

---

Checklist:

• Added the change to the changelog's "Unreleased" section with a link to this PR and your username
• Linked any existing issues or proposals that this pull request should close
• Updated or added relevant documentation in the README and/or documentation directory
• Added a test for the contribution (if applicable)

[chtenb]

If I'm not mistaken, this changes the behavior of the function in case of a parser error in p due to the usage of try. PS I'm currently on vacation and may not be very swift to respond.

[hjmtql]

What you pointed out is correct.
Thanks for the quick review.

[hjmtql]

NOTE

It gets

> runParser (sepEndBy (char 'a') (char ';')) "a;b"
(Right ('a' : Nil))

It seems that b is trashed. I think this is a little problem.

I found this result occurs also in original sebEndBy.
I wonder if it is the intended behavior.

[chtenb]

Hm yeah, I can't think of obvious situations where this would be what you want. In test/BasicSpecs.purs we have some basic specs that say what should be parsable and what shouldn't. Perhaps we should extend these specs to also cover partial successes and assert on the expected remaining unparsed string.

We should also look at what purescript-parsing does in these cases.

[chtenb]

I would naievely expect sepEndBy to successfully parse a separated sequence and whenever either the sep or the p fails to just stop parsing and yield what has been parsed so far.