multiSelect and <|> both have similar challenges for control flow
can multiSelect be phrased in terms of <|> and select? idk it kind of seems like a bad idea, outside the land of parsers
you'd probably have trouble arguing it if you have nontrivial effects on the left side of select; it would rely on factoring those out
so it would need to be idempotent …?
sleepy
(unrelated thought: I wonder if the order of alternatives could be semantically significant in LR or Earley parsing; can you maintain it consistently in state and use it to disambiguate?)
what type signature would I give multiSelect in PureScript?
forall f ri rfo o.
Selective f =>
… forall l, rfio[l] = f (ri[l] -> o) …
f (Variant ri) -> Record rfio -> f o
It's like match but each case has a statically known effect f around its function (the key part being you can enumerate these ahead of time – although if you care about order, you're stuck with string sorting order)
okay let's get a Menhir/OCaml-inspired syntax going
looks up what Menhir looks like again
int:
| d = digit
{ d }
| v = int; d = digit
{ 10*v + d }
// a higher order parser
// parses an integer, and then that many of the given parser
// (this makes it context-sensitive)
length_prefixed(parser):
// I need to verify that passing { amt } makes sense semantically
// (that seems necessary to have unbounded repetition here)
| amt = int; r = length_prefixed_aux(parser){ amt }
{ r }
// a higher order parser
// that also takes a value too?
length_prefixed_aux(parser){ amt }
match amt with
// if amt = 0, we return an empty list
| 0 ->
{ [] }
// otherwise we parse one, and recurse
// (decrementing amt)
| (n+1) -> head = parser; more = length_prefixed_aux(parser){ n }
{ head :: more }
