Sharp-edge with a OneOf printer ending with a "catch-all" fallback case.

[tgrapperon]

Hello!

I was recently working on a parser-printer that had to parse the enum:

enum Enum {
  case someCase(String, [Param] = [])
}

When there are no parameters, the input looks like

"someCase:SomeString"

and, with parameters:

"someCase:SomeString-param1,param2,param3"

Let say that params is a Many parser of non-empty [Param], I can then write a parser for each configuration:

let someCaseWithParams = ParsePrint {
  PrefixUpTo("-").map(.string)
  "-"
  params
}

let someCaseWithoutParams = ParsePrint {
  Rest().map(.string)
  Always([Param]())
}

I would then write this enum case as

let someCase = ParsePrint(.case(Enum.someCase)) {
  "someCase:"
  OneOf {
    someCaseWithParams
    someCaseWithoutParams
  }
}

It parses correctly the strings I'm sending to it. But when I try to print someCase with params, it generates a someCase without params. This is because the current form of someCaseWithoutParams is able to print a case with params, and since it's the first one tried, it's the one that is used to print the value.

Fortunately, it is easy to fix: if I change for example someCaseWithoutParams to be

let someCaseWithoutParams = ParsePrint {
  Not { PrefixUpTo("-") }
  Rest().map(.string)
  Always([Param]())
}

…well, it doesn't work. This parser still manages to print a case with params because when it arrives at Not when printing, it has already written the whole string in Rest's, and it runs the Not on an empty string.

We can fix this by reversing the order of parsers:

let someCase = ParsePrint(.case(Enum.someCase)) {
  "someCase:"
  OneOf {
    someCaseWithoutParams
    someCaseWithParams
  }
}

And this parser printer works fine in both directions.

So in this case, we unfortunately had to:

• Bake some exclusion-logic into the "fallback" parser;
• Reverse the "natural" order of parsers.

The Rest/Always combination is the root of all evil here. I've inserted the Always because I wanted the parser to be homogenous and output (String, [Param]), but all problematic behaviors are caused by their unconstrained nature.

I have yet to find an elegant solution to this rather simple problem. I had to jump back into Parsing to solve a specific issue while working on another problem for days, so I'm maybe missing something obvious.

[iampatbrown]

@tgrapperon would something like this work?

let someCase = ParsePrint(.case(Enum.someCase)) {
  "someCase:"
  Prefix { $0 != "-" }.map(.string)
  Parse {
    "-"
    params
  }
  .replaceError(with: [])
}

or this?

let someCase = ParsePrint(.case(Enum.someCase)) {
  "someCase:"
  Prefix { $0 != "-" }.map(.string)
  OneOf {
    Parse {
      "-"
      params
    }
    End().map { [Param]() }
  }
}

[tgrapperon]

Indeed. Good catch for the End instead of Always that nails the result. We should always constrain Parsers as much as possible and I missed this. Both will behave the same at the end of parsing, and this kind of degenerate situation can be tricky sometimes. I also missed that .map could print an Equatable when the output is Void. The same with replaceError. I haven't used a lot Parsing since printers, so I'm a little rusty on this side.

I think replaceError() is the "natural" choice here, but I find the naming a little counter-intuitive in this case, and that's probably why I didn't think about it. Optional documentation even mentions this parser as a coalescing result to optional parsers, which is what I was looking for mentally. I should have checked more thoroughly. If we would overload ?? with:

public func ?? <P: Parser>(parser: P, default: P.Output) -> Parsers.ReplaceError<P> {
  parser.replaceError(with: `default`)
}

we could rewrite the parser as

let someCase = ParsePrint(.case(Enum.someCase)) {
  "someCase:"
  Prefix { $0 != "-" }.map(.string)
  Parse { "-"; params } ?? []
}

which I find much more appealing. Do you think it could be worth a PR?

BTW, I've experimented with ExpressibleByStringInterpolation to try to build parsers like "someCase:\(parser)", but without success for now as the API is array-backed. It looks possible in some specific cases however, but I didn't had the time to push farther. But it would be wild to be able to write "-\(params)" ?? [] instead of Parse { "-"; params }.replaceError(with: [])!