I’ve opened a PR which would delete the Text.Parsing.Parser.String.StringLike typeclass from the purescript-parsing package.
Would this cause trouble for anyone if it were merged?
More generally, does anyone use this package? Please reply if you use it, I’d like to know who the users are.
I was talking to James about this today in a PureScript Contrib call. In short, we’re trying to reduce the “fear of the unknown” of the breakage this change might cause. This post is an attempt to find the people who use this library and how, so that they might be included in the conversations around changes we could make.
If no one uses this library, then that gives James more freedom to make design decisions as he sees fit.
I use the library for toy languages and didn’t even know about the typeclass 
I use it, just for toy projects, and I’ve never parsed any StringLike thing besides String.
I have never taken advantage of StringLike, but I believe it exists so you can do things like parse using List Char if you were so inclined. What would need to change to handle unicode properly with StringLike (the requirements of this alternative were not mentioned in the ticket)? Was there discussion about why StringLike was introduced, or was it just “maybe this is useful”?
What would need to change to handle unicode properly with StringLike (the requirements of this alternative were not mentioned in the ticket)?
Basically, uncons’s head value can no longer have type, Char.
Now that yall mentioned unicode, I wonder, is the dependency on the unicode package really necessary? I’m pretty sure I had to drop this lib from a previous project because of the insane bundle sizes (ended up ffi-ing to nearley)
Then I agree that removing StrinkLike is probably for the best.
I agree that purescript-unicode leads to excessive bundle sizes. I don’t think there’s a reason that it couldn’t be trimmed significantly, but it would require someone making a dedicated effort to help with that.
StringLike was introduced by Phil “to support more efficient string representations” in Updates for 0.10 by paf31 · Pull Request #36 · purescript-contrib/purescript-parsing · GitHub
No-one ever wrote a List Char instance of StringLike, instead @cdepillabout created the Text.Parsing.Parser.Token - purescript-parsing - Pursuit module, which works very well.
So, I kinda wonder, is there any advantage of using a list of tokens instead of a zipper array?
I’m probably about to be schooled because there’s a better way to do this (or maybe it already exists!), but I recently had to write something like:
word :: Parser String String
word = do
chars <- some alphaNum
pure $ String.fromCodePointArray $ (String.codePointFromChar <$> chars)
which I could imagine being simpler if I was parsing a List Char instead of a String. Still I doubt there would be cases where it would be advantageous for a whole parser to work on List Char when you consider performance.
Currently there is no better way to write your word parser, but there should be. Deleting the StringLike class will allow us to add new primitive parsers like takeWhileP :: (CodePoint -> Boolean) -> Parser String String so that we can take advantange of the O(1) JavaScript immutable String slicing and write your parser as
word :: Parser String String
word = takeWhileP isAlphaNum
Interesting!
I use StringLike a => a lot, but only because a heap of code I was using used it and defining my own stuff as String → broke stuff when composing the parsers - in that way it was a annoyingly viral.
So as much as it’d be a pain for me to strip it from my own parsers, the ported parsers (I think perhaps formatters?) and the datetime-parser, I’d be in favour of this because it’d mean that kind of code wouldn’t be needed.
I use the Erlang backend, which has… immutable string slicing so I imagine anything we do could take advantage of this too when re-writing the FFI.
We have the match combinator for String now, which helps in the case of parsers like your word parser @ntwilson . Parsing.String - purescript-parsing - Pursuit