add custom state to parsers

README.md

@@ -17,15 +17,14 @@ Define a type-level parser:
 
 ```haskell
 import Symparsec
-import DeFun.Core
 type PExample = Skip 1 *> Tuple (Isolate 2 NatHex) (Literal "_" *> TakeRest)
 ```
 
 Use it to parse a type-level string (in a GHCi session):
 
 ```haskell
-ghci> :k! Run PExample "xFF_etc"
-Run ...
+ghci> :k! Run' PExample "xFF_etc"
+Run' ...
 = Right '( '(255, "etc"), "")
 ```
 

TODO.md

@@ -1,16 +1,31 @@
 # Symparsec to-dos
+* custom state necessitates `TypeAbstractions` (GHC 9.8) sometimes: clarify
+
 ## Proofs (tests?)
 * `Isolate n TakeRest` is equivalent to `Take n`
 
 ## Combinators
-* `Choice :: [PParser a] -> PParser a`
-* various from parser-combinators, megaparsec (e.g. `sepBy`)
+* `Fold`. `Foldr`, I guess? Idk.
+* various from parser-combinators, megaparsec. find out the most common/used
 
 ## Example uses of Symparsec to write, present
-### generic-data-functions
-Fiddly and awfully abstract. WIP.
+### Generics, parsing constructor & field names
+* generic-data-functions: done for 1.0. fiddly and awfully abstract. TODO
+* aeson: super real world! do constructor & field name parsing, instead of
+  `constructorTagModifier` and such. pretty daunting though (nasty generics)
+
+### JSON parser
+Big, real world, funny. Roll it by hand (Aeson's parsing is very complex).
+
+## Completed examples
+Just to remind myself what is already attempted.
+
+### Expression parser
+Not very well-written, mind you, but it works. I could probably write a
+`MakeExprParser` like in megaparsec, but it's terribly complex.
+
+### Format string parser
+Directly from typelits-printf, minimal changes.
 
-### aeson
-Big but real world. Write some new aeson generics which do type-level
-constructor name parsing, instead of using `constructorTagModifier`. Daunting
-because aeson has complex generics.
+### Something that uses multi-line `Symbol`s
+Threw into the expression parser. 9.12 exclusive due to `MultinelineStrings`.

docs/formatting.md

@@ -16,15 +16,19 @@ defunctionalized arrow. This means some promoted types might not actually use
 the term-level type directly. That's fine.
 
 ## Binders
-* parser string type binder: `str`
+* parser state string type: `str`
   * don't use `sym`.
-* parser return type binder: `a`
-* parser reply type binder: `rep`
+* parser state numeric type: `n`
+  * slightly preferred over `i` because it's a `Natural`
+* parser return type: `a`
+* parser reply: `rep`
   * ? `r` is fine, but it's often used for continuations. `rep` sounds like
     `representation` but that's it, so I consider it fairly unambiguous
-* parser state type binder: `s`
-* parser state index type binder: `idx`
+* parser state: `ps`
+* parser state custom state: `s`
+  * TODO. term/type s/s is fine because separate namespaces, but type/kind s/s
+    doesn't work, so I need to use type/kind custom/s. I should do the same for
+    all uses. TODO annoying refactor. maybe use `cst` if you want shorter?
+* parser state index: `idx`
   * simple, obvious
-* parser state number kind binder: `n`
-  * slightly preferred over `i` because it's a `Natural`
-* parser error type binder: `e`
+* parser error: `e`

src/Symparsec.hs

@@ -5,15 +5,17 @@ I suggest importing this module qualified. Or, consider the following imports:
 @
 import "Symparsec.Run" qualified as Symparsec
 import "Symparsec.Parsers" qualified as P
--- > :k! Symparsec.Run (P.Take 1) "hello"
+-- > :k! Symparsec.'Run'' (P.Take 1) "hello"
 @
 -}
 
 module Symparsec
   (
   -- * Base definitions
     type Run
+  , type Run'
   , type RunTest
+  , type RunTest'
 
   -- * Parsers
   , module Symparsec.Parsers