Help with using OneOf to handle different parse data

[sillygoose]

Building a parser of vehicle OBDII responses and have a case where the normal and error responses are different. For example I typically receive the response:

STPX h:0720, d:22404C\n62 40 4C 02 16 02\n\n>

But I can also get an error responses similar to these:

STPX h:0720, d:22404C\nCAN ERROR\n\n>"
STPX h:0720, d:22404C\nNO DATA\n\n>

My initial parser for the non-error response is to parser the command followed by the response:

let stpxResponseParser = Parse(STPX.Response.init(uds:did:data:)) {
    hexByte
    Whitespace(.horizontal)
    hexWord
    Whitespace(.horizontal)
    hexBytes
}

let stpxCommandParser = Parse(STPX.Command.init(module:did:)) {
    hArgumentParser
    argumentSeparator
    dArgumentParser
    newLine
}

let stpxParser = Parse {
    stpxCommandParser
    stpxResponseParser
    responseTail
}

but now I am trying to add in parsing of the error cases so I replaced the stpxResponseParser parser with a parser that uses OneOf:

let stpxNormalResponse = Parse(STPX.Response.init(uds:did:data:)) {
    hexByte
    Whitespace(.horizontal)
    hexWord
    Whitespace(.horizontal)
    hexBytes
}

let stpxErrorResponse = Parse(STPX.Error.init(error:)) {
    obdResult // these are the error strings
}

let stpxResponseParser = Parse {
    OneOf {
        Parse { stpxNormalResponse }
        Parse { stpxErrorResponse }
    }
}

The problem is I get a compiler error that has me confused and could use some help resolving. If I comment out either of the OneOf parsers I get correct results but with both there I get a compiler error:

Static method 'buildPartialBlock(accumulated:next:)' requires the types 'STPX.Response' and 'STPX.Error' be equivalent 

I naively wished for the non-error response to be tried first and if it failed match the error conditions would be parsed but this compiler error has me stuck. Any suggestions for writing a parser for the two types of responses would get me going again.

Thanks

Rick

P.S. If it helps here some other bits of the parser that might be useful:

struct STPX {
    struct Command {
        let module: UInt16
        let did: UInt16
    }
    struct Response {
        let uds: UInt8
        let did: UInt16
        let data: [UInt8]?
    }
    struct Error {
        let error: ObdResult
    }
}

enum ObdResult: String, CaseIterable {
    case OK = "OK"
    case INVALID = "?"
    case STOPPED = "STOPPED"
    case BUFFER_FULL = "BUFFER FULL"
    case CAN_ERROR = "CAN ERROR"
    case NO_DATA = "NO DATA"
}

let obdResult = OneOf {
    for result in ObdResult.allCases {
        result.rawValue.map { result }
    }
}

[sillygoose]

After much playing around (and learning) I decided to leave OneOf behind - seems all the types must match and it isn't possible or I am unable to figure out a solution.

So I added a parser just for the error case and went to top of parser and added it to the failing case:

        case .STPX:
            do {
                let stpxCommand = try stpxParser.parse(cmd.1)
                print(stpxCommand)
            } catch {
                do {
                    let stpxError = try stpxErrorResponse.parse(cmd.1)
                    print(stpxError)
                } catch {
                    print(error)
                }
            }

Now my test cases pass and I can start using the parser in real code. But if anyone has a comment or suggestion on using OneOf I would love to learn a better way of doing things.

[tgrapperon]

Hey @sillygoose! Sorry, I don't have the time right now to dive deep into your case, but OneOf is generally a parser of enums (with or without associated values). So two things:

• Your domain can be modelled with one enum that hosts the two cases OneOf can parse:

enum SPTXResponse {
  case success(STPX.Response)
  case failure(STPX.Error)
}

But if you look at the generic signature, this is exactly a Result<STPX.Response, STPX.Error>, so I would look if I can refactor what's coming next to use a Result, as you may find positive side-effects to this "better" modelization, furthermore with the nice amenities Result already has regarding throwing functions. With a little more info about the context where this type is used, we could probably give more explicit indications. But it seems that you would be able to avoid the do/catch that you're doing in case .STPX, as Result would be able to support any outcome.

• Your domain can't be modelled with one such enum, and OneOf will likely not be the right tool for the job indeed.

I hope it helps. Feel free to let me know if things are not clear.

[sillygoose]

Spent some time rewriting everything, using enum cases for the OneOf parsers and using Result for the response. Your suggestions were perfect, thanks for the help.

The only quirk is handing the case when there is nothing to parse. For each request I parse the command, its arguments, and the response to a structure:

struct Obd {
    let command: ObdCommand
    let arguments: ObdArgments
    let response: ObdResult
    init(command: ObdCommand, arguments: ObdArgments, response: ObdResponse) {
        self.command = command
        self.arguments = arguments
        if case .failure = response {
            self.response = .failure(response)
        } else {
            self.response = .success(response)
        }
    }
}

and each command parser looks like this:

let stpxParser = Parse(Obd.init(command:arguments:response:)) {
    stpxCommandParser
    stpxArgumentParser
    stpxResponseParser
    parseResponseTail
}

Not all commands have arguments but you have to parse something so I found this workaround to let me collect commands with empty arguments:

let atzArgumentParser = Parse {
    ObdArgments.init(arguments: .atz)
} with: {
    Not { "Don't parse anything" }
}

Except for this everything seems to work and it is extensible, just add the command, argument, and response parsers for the new command, add the new case to the enums and done.

[tgrapperon]

I can't really say if this is the right solution, but in any case, you also have the Optionally parser that will parse nil if it fails, so maybe you can model your domain using optionals too.
Alternatively, if you're looking for a parser that always succeed, there is the Always parser. This is maybe a better alternative than Not { "…" }.

[sillygoose]

I tried Always but just got compiler errors, probably something else I don't understand. But I am already moving on since in the real code I will know what command was sent so I can specify the exact response parser to be used rather than trying them all and see what matched.

I would like to mark this as answered but GitHub doesn't give me the option on your replies. Just want all to know that you deserve all the credit for setting me straight on parsing, even if I have to mark one of my posts as the answer - thanks again for your help.

[tgrapperon]

I'm glad you got it sorted, that's what matters!

[sillygoose]

I’ll give that a try, right now I am just running in a playground seeing what works. None of the benchmarks had anything other than Substrings in the OneOf examples I could find so this is a nice idea to follow up with.

Thanks a bunch for replying need all the help I can get building two TCA apps, this one pulling real-time vehicle data over Bluetooth from an OBDII dongle and sending it to the cloud. And the dongle uses the AT protocol from the 1980’s which looked perfect for the Pointfree parsing package.