Parse a string URL to Enum?

[chefnobody]

Long time listener, first time caller.... 😅

Below I have a urlParser that chains via orElse's 2 other parsers with increasing complexity to map a String to a Route. This works, however a few things feel off or altogether not optimal.

1. The compiler complained at me for not explicitly ignoring the input to the .map operators in root and account .... "Contextual type for closure argument list expects 1 argument, which cannot be implicitly ignored". I'm guessing this is because I started with PrefixThrough<Substring> rather than skipping that prefix? I wasn't certain how to start the parser chain to get the effect I wanted.

2. I ran into compiler complexity problems with the long chain of skipped parsers and having distinct parsers defined helped with that. Is that a good practice wrt to long-chains of parsers?

3. Am using the correct parsers and/or combining them in the right ways?

enum Route {
    case root
    case account
    case verifyPhone(code: String)
}

let customProtocol = PrefixThrough<Substring>("dead-beef://")
let accountPath = PrefixThrough<Substring>("account")
let verifyPath = PrefixThrough<Substring>("verify")
let phonePath = PrefixThrough<Substring>("phone")
let slash = Prefix<Substring> { $0 == "/" }
let query = Prefix<Substring> { $0 == "?" }
let codeKey = PrefixThrough<Substring>("code")
let equals = Prefix<Substring> { $0 == "=" }

let root = customProtocol
    .take(End())
    .map { _ in Route.root }

let account = customProtocol
    .skip(accountPath)
    .take(End())
    .map { _ in Route.account }

let verifyPhone = customProtocol
    .skip(accountPath)
    .skip(slash)
    .skip(verifyPath)
    .skip(slash)
    .skip(phonePath)
    .skip(query)
    .skip(codeKey)
    .skip(equals)
    .take(Int.parser())
    .map { String.init($0.1) }
    .take(End())
    .map { Route.verifyPhone(code: $0.0) }

let urlParser = root
    .orElse(account)
    .orElse(verifyPhone)

let rootUrl = "dead-beef://"
let accountUrl = "dead-beef://account"
let verifyPhoneUrl = "dead-beef://account/verify/phone?code=12345"


urlParser.parse(rootUrl)
// => root
urlParser.parse(accountUrl)
// => account
urlParser.parse(verifyPhoneUrl)
// => verifyPhone(code: "12345")

As a quick follow up I wrote some tests and found this isn't working as I'd suspect. .skip isn't doing what I thought it would.

This malformed Url successfully parses out the code:

let badVerifyPhoneUrl = "dead-beef://account/verify/phonecode12345"
urlParser.parse(badVerifyPhoneUrl)
// => verifyPhone(code: "12345")

I'm definitely doing something wrong, here. What's the correct Parser/Operator to use to ensure a token is in the string, failing if it is not?

[mbrandonw]

I'm guessing this is because I started with PrefixThrough<Substring> rather than skipping that prefix? I wasn't certain how to start the parser chain to get the effect I wanted.

Ah yes, the PrefixThrough is a parser that outputs strings, and so to discard that and turn it into a Void parser you need to use Skip(...):

let customProtocol = Skip(PrefixThrough<Substring>("dead-beef://"))

I ran into compiler complexity problems with the long chain of skipped parsers and having distinct parsers defined helped with that. Is that a good practice wrt to long-chains of parsers?

Yes, super long chains can definitely bog down the compiler, which also happens with super long chains of lazy array operations. For example this takes a really long to compile:

let tmp = Array(1...100)
  .lazy
  .map { $0 + 1 }
  .filter { $0 % 2 == 0 }
  .map { $0 + 1 }
  .filter { $0 % 2 == 0 }
  .map { $0 + 1 }
  .filter { $0 % 2 == 0 }
  .map { $0 + 1 }
  .filter { $0 % 2 == 0 }
  .map { $0 + 1 }
  .filter { $0 % 2 == 1 }

It can be helpful to break out large parsers into a few smaller ones.

Am using the correct parsers and/or combining them in the right ways?

What you are doing here can definitely work, but it's sometimes easier to work with an intermediate type to parse rather than going directly to string. For example, we have a router example in this repo and we chose to first convert URL strings into a RequestData type that takes care of sorting through the path components, query params, headers, etc. Then we write parsers on that type to incrementally consume bits from it, like this Path parser that is responsible for parsing a single path component from the request.

Working on this more structured data types makes it so that you don't have to worry about nitty gritty details like slashes, equal signs, etc.