You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/src/index.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,7 +20,7 @@ Why another parsing library? See this [blog post detailing the
20
20
design](https://posco.medium.com/designing-a-parsing-library-in-scala-d5076de52536). To reiterate,
21
21
this library has a few goals:
22
22
23
-
1.Compatability: should work on all scala platforms and recent versions. Currently it supports JVM, JS on versions 2.11, 2.12, 2.13, and 3. The core library should have minimal dependencies. Currently this library only depends on cats.
23
+
1.Compatibility: should work on all scala platforms and recent versions. Currently it supports JVM, JS on versions 2.11, 2.12, 2.13, and 3. The core library should have minimal dependencies. Currently this library only depends on cats.
24
24
2. Excellent performance: should be as fast or faster than any parser combinator that has comparable scala version support.
25
25
3. Cats friendliness: method names match cats style, and out of the box support for cats typeclasses.
26
26
4. Precise errors: following the [Haskell Trifecta parsing library](https://hackage.haskell.org/package/trifecta), backtracking is opt-in vs opt-out. This design tends to make it easier to write parsers that point correctly to failure points.
0 commit comments