Conditional parsing based on previous output

[andrews05]

swift-parsing v0.9.2

I'm trying to parse input consisting of a single character op code followed by an int. E.g. "A12", "B50", "C4". This is simple enough to parse using an enum for the opcodes and a struct to pair the op with the int.
My problem is I now want the int to be optional, but only for one of the op codes (opC in my example below). I've come up with two different solutions for this, shown below, but neither seems ideal so I'm wondering how it could be done better.

Method 1 uses OneOf to parse either (any op code + int value) or (specific op code without int value). This works, but won't scale if I need to add more than one op code like this.
Method 2 parses an op code, then uses flatMap to parse either a required int or an optional int, depending on the op code. This can easily scale if I more op codes, but seems to make the error output slightly wrong.

Are there any better ways to achieve this?

enum Op: String, CaseIterable {
    case opA: "A"
    case opB: "B"
    case opC: "C"
    // And many more...

    var valueRequired: Bool {
        switch self {
        case .opC:
            return false
        default:
            return true
        }
    }
}

struct OpWithValue {
    let op: Op
    let value: Int?
}

// Method 1
let OpParser1 = OneOf {
    Parse(OpWithValue.init) {
        Op.parser()
        Int.parser()
    }
    Op.opC.rawValue.map {
        OpWithValue(op: .opC, value: nil)
    }
}

// Method 2
let OpParser2 = Parse {
    Op.parser(of: Substring.self)
}.flatMap { op in
    if op.valueRequired {
        Int.parser().map {
            OpWithValue(op: op, value: $0)
        }
    } else {
        Optionally {
            Int.parser()
        }.map {
            OpWithValue(op: op, value: $0)
        }
    }
}

[tgrapperon]

Hey @andrews05. There are indeed several ways to implement a solution to your problem, but the simplest is probably to attack it at its root: OpWithValue is a type that allows incoherent states (that is opA with a nil value for example). It means that you need to take of this at the parser level and prevent it to create such values by failing if the input is not coherent. You can for example use filter to discard invalid configurations.

But I feel that it would be preferable to model your domain so it prevents incoherent states. One way to do it is to make the code in the enum:

enum Op {
  case opA(Int)
  case opB(Int)
  case opC(Int?)
}

You can then create a few helpers:

extension Op {
  static func withValue(
    _ label: Substring,
    as case: @escaping (Int) -> Op
  ) -> some Parser<Substring, Op> {
    Parse(`case`) {
      StartsWith(label)
      Digits()
    }
  }
  static func withOptionalValue(
    _ label: Substring,
   as case: @escaping (Int?) -> Op
  ) -> some Parser<Substring, Op> {
    Parse(`case`) {
      StartsWith(label)
      Optionally {
        Digits()
      }
    }
  }
}

extension Op {
  static var parser: some Parser<Substring, Self> {
    OneOf {
      withValue("A", as: opA)
      withValue("B", as: opB)
      withOptionalValue("C", as: opC)
    }
  }
}

I feel that this thing scales relatively well: if you add one case, you add one line to the OneOf parser. It can also seamlessly handle very exotic cases. Of course you're losing the CaseIterable aspect, but you're saving on the "Optional" exceptions, and you get "safer" values to work with downstream.

Note that I nested everything in Op, but this is not required and you can define these as free functions.

This is my personal take on the problem, and your solution has its merits too, so you should really use what you're most confortable with, especially depending on how this values are used once they're parsed.

[tgrapperon]

If you define the helpers into some String extension instead, you can build an even more fluent parser:

extension String {
  fileprivate func withValue(as case: @escaping (Int) -> Op) -> some Parser<Substring, Op> {
    Parse(`case`) {
      StartsWith(self[...])
      Digits()
    }
  }
  
  fileprivate func withOptionalValue(as case: @escaping (Int?) -> Op) -> some Parser<Substring, Op> {
    Parse(`case`) {
      StartsWith(self[...])
      Optionally {
        Digits()
      }
    }
  }
}

extension Op {
  static var parser: some Parser<Substring, Self> {
    OneOf {
      "A".withValue(as: opA)
      "B".withValue(as: opB)
      "C".withOptionalValue(as: opC)
    }
  }
}

[andrews05]

Thanks heaps for your reply, that looks like a really tidy solution!
I had initially started with a enum with associated values, but changed it to RawRepresentable because I didn't want to have to specify each case in the parser 😅. Incoherent states wouldn't actually be a problem in my case. But I'll give your implementation a go and see how I get on 🙂

[tgrapperon]

I chatted with @iampatbrown on Slack, and it seems that you can also rewrite your parser of OpWithValue as:

Parse(inputType: Substring.self, OpWithValue.init) {
  Op.parser()
  Optionally {
    Digits()
  }
}
.filter { !$0.op.valueRequired || $0.value != nil }

Under this form, invalid OpWithValue are potentially created for a few cycles, which can be problematic in some setups (this is not the case here, but imagine creating a Range<Int> with lowerbound >= upperbound). But you can also filter earlier:

Parse(inputType: Substring.self, OpWithValue.init) {
  Parse {
    Op.parser()
    Optionally {
      Digits()
    }
  }
  .filter { !$0.0.valueRequired || $0.1 != nil }
}

Another potential solution initially suggested by @iampatbrown was to implement a fallible initializer of OpWithValue (that fails if there is no value when it's required). You can then simply compactMap:

Parse(inputType: Substring.self) {
  Op.parser()
  Optionally {
    Digits()
  }
}
.compactMap(OpWithValue.init)

But you lose the automatic memberwise conversion of OpWithValue, so you'd need to work a little more if you wanted to turn this into a ParserPrinter. Otherwise, you could simply make it a printer too as:

ParsePrint(inputType: Substring.self, .memberwise(OpWithValue.init)) {
  Op.parser()
  Optionally {
    Digits()
  }
}
.filter { !$0.op.valueRequired || $0.value != nil }

As you see, they are many ways to approach your problem. My initial suggestion to use an enum with associated values may be cumbersome to use downstream if you need to split up Op and Value again, so you also have these solutions if your's doesn't work as expected.

[tgrapperon]

Also please note that the various inputType: Substring.self are coming from the fact that I'm using the swift-5-8 branch on Xcode 14.3b2. It is possible that we can drop a few of them.

[andrews05]

Thank you so much, really appreciate all the ideas! I'll try them all out and see which one best fits my needs.

[andrews05]

Another option I explored:

OneOf {
    for op in Op.allCases {
        Parse(OpWithValue.init) {
            op.rawValue.map { op }
            if op.valueRequired {
                Digits().map { $0 as Int? }
            } else {
                Optionally { Digits() }
            }
        }
    }
}

This one has the most helpful/accurate error diagnostic on failure.