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 }

You must log in to comment.