Introduce TryParse?

[rjchatfield]

Feature Suggestion: Wondering if you'd contemplate a variant of Parse { } that takes a fallback value?

I know you have suggested this approach:

OneOf {
  Parse {
    Int.parser()
    ","
    Prefix { $0 != "," }.map(String.init)
    ","
    Bool.parser()
  }
  Always(fallbackValue)
}

In my own project I made a type called TryParse that is a helper wrapper of this.

Usage:

TryParse {
  Int.parser()
  ","
  Prefix { $0 != "," }.map(String.init)
  ","
  Bool.parser()
} catch: {
  fallbackValue
}

Implentation:

public struct TryParse<FirstTry>: Parser where FirstTry: Parser {
  public let parser: OneOf<Parsers.OneOf2<FirstTry, Always<Input, Output>>>

  @inlinable
  public init(
    @ParserBuilder _ tryBlock: () -> FirstTry,
    `catch` catchValue: () -> FirstTry.Output
  ) {
    parser = OneOf {
      tryBlock()
      Always<FirstTry.Input, FirstTry.Output>(catchValue())
    }
  }
  
  @inlinable
  public func parse(_ input: inout FirstTry.Input) -> FirstTry.Output {
    parser.parse(&input)!
  }
}

I realise I'm missing the convenience of Parse(User.init) { }. I respect any suggestions or bikeshedding of names.

[iampatbrown]

@randomeizer has had some cool parser suggestions as well. Have you seen hsdoc/parse-throws which includes a Try parser? You two might be able to share some ideas.

[rjchatfield]

That's great! Thanks for sharing.

[randomeizer]

Yeah, I'm still baking mine, based on how the library I'm using it in develops. But something like Try or TryParse (yeah, not sure about the name exactly either) would definitely be helpful.

At the moment my library has some similar parsers which feel like they have overlap, so probably should be boiled down a little.

[stephencelis]

@randomeizer As a side note it's been very cool watching your project develop. Thanks for contributing back discussions about your experience 😄 (and PRs!)

[randomeizer]

@stephencelis No worries! I'm just glad you guys are revisiting this at the moment, since the new developments are definitely helpful. Just before you mentioned the impending throws branch I had started figuring out how to make returning Result<Output,Error> values more ergonomic to get better error output, since I didn't really want to fork it to add throws myself, haha.

[tgrapperon]

This is indeed a great idea. There is a ReplaceError parser with the same functionality in the "throw" branches:
https://github.com/pointfreeco/swift-parsing/blob/pb-throws-ep1/Sources/Parsing/Parsers/ReplaceError.swift
It accepts a defaultValue directly, where Try from @randomeizer uses a closure with the error as argument. The later seems more flexible, and ReplaceError should probably use a closure like this (with a dedicated init for constants) if there are no deep consequences down the line regarding printing.

[randomeizer]

So, you would have signature something like ModifiedParser<Many, AtMost>?

[tgrapperon]

Likely. But I need to tackle the typing issues first. ViewModifier is a protocol that comes with a typealias, which is not common.
The ModifiedParser is the parser that builds the modified parsing element, that is, that runs the func parser(upstream: Upstream) -> some Parser from Modifier, but Upstream is a typealias from ViewModifier, and the function is not generic over it. In SwiftUI, it aliases a type that is private to the ViewBuilder. How they can wrap things without erasing the types too much is still nebulous. That's the tricky part.

I sincerely don't know how far it can go yet, nor how much it can affect performance and other metrics. Parsers are absolutely focused on performance, but at worse, the experiment can provide ideas for the protocolized version of TCA which is evolving in the same space.

[randomeizer]

Just skimming through the public API for ViewBuilder/ViewModifier, it seems like the Content is being mapped to a View via the @ViewBuilder annotation on ViewModifier.body(content:), but I'm still wrapping my head around parts of Swift's generics implementation TBH.

Do you have an exploratory branch up somewhere for this yet?

[tgrapperon]

@randomeizer Not yet. I haven't got the time to work on this yet.

[randomeizer]

Ok, I'll keep an eye out for it.

[stephencelis]

Feature Suggestion: Wondering if you'd contemplate a variant of Parse { } that takes a fallback value?

We actually added a replaceError(with:) parser modifier in this release that achieves just that! I'll update the release notes accordingly.

[Edit: release notes updated with this and a few other changes/additions, thanks!]

I know you have suggested this approach:

OneOf {
  Parse {
    Int.parser()
    ","
    Prefix { $0 != "," }.map(String.init)
    ","
    Bool.parser()
  }
  Always(fallbackValue)
}

We've now specifically added documentation advising against this approach, now that we use rethrowing parsers:

• swift-parsing/Sources/Parsing/Parsers/Always.swift

  Lines 61 to 63 in 9145db3

  	/// > Note: While `Always` can be used as the last alternative of a ``OneOf`` to specify a default
  	/// > output, the resulting parser will be throwing. Instead, prefer ``Parser/replaceError(with:)``,
  	/// > which returns a non-throwing parser.

• swift-parsing/Sources/Parsing/Parsers/OneOf.swift

  Lines 37 to 53 in 9145db3

  	/// If you are parsing input that should coalesce into some default, avoid using a final ``Always``
  	/// parser, and instead opt for a trailing ``replaceError(with:)``, which returns a parser that
  	/// cannot fail:
  	///
  	/// ```swift
  	/// enum Currency { case eur, gbp, usd, unknown }
  	///
  	/// let currency = OneOf {
  	/// "€".map { Currency.eur }
  	/// "£".map { Currency.gbp }
  	/// "$".map { Currency.usd }
  	/// }
  	/// .replaceError(with: Currency.unknown)
  	///
  	/// currency.parse("$") // Currency.usd
  	/// currency.parse("฿") // Currency.unknown
  	/// ```

In my own project I made a type called TryParse that is a helper wrapper of this.

Usage:

TryParse {
  Int.parser()
  ","
  Prefix { $0 != "," }.map(String.init)
  ","
  Bool.parser()
} catch: {
  fallbackValue
}

This is neat way of approaching things with builders! As I also replied here, we're definitely open to tweaking the ergonomics here, but it'd be a good idea to figure out a style guide for when to use parser builders over parser modifiers.

[randomeizer]

In my own Try implementation I was have also tossed up whether to make it a top-level Parser or a modifier. One thing I like about it being a Parser is that it stands out, which I think is probably a good thing given that it's changing error flow control quite substantially. That said, replaceError is simpler, and basically works like map.

In my case, my Try {} catch: {err in } lets you either return a compatible Output or throw any error, which is handy for making error messages more context-aware. For example:

let tenChars = Try {
    Parse(10) { !$0.isNewline }
} catch: { error in
    throw MyError.expected("exactly 10 non-newline characters")
}

This could equally be implemented as a modifier, which would look like:

let tenChars = Parse(10) { !$0.isNewline }.catchError { error in
     throw MyError.expected("exactly 10 non-newline characters")
}

I actually kinda prefer the Parser version, in that the parser and the error handling are at the same indentation level (in my formatting anyway), whereas the .catch {} version feels like more of an afterthought, and I feel would be more prone to misreading exactly what part of the parser is getting caught.

[stephencelis]

@randomeizer One consideration with making Try's catch block throwing is the resulting parser will still be throwing, whereas replaceError(with:) always turns a throwing parser into a non-throwing one.

@rethrows doesn't seem to work for throwing closures held as properties like the one you invoke in catch, probably because they are dynamic, vs. a conformance, which is static. One of the primary use cases of replaceError(with:) is if you use it liberally, you can cook up with a parser that statically cannot throw, which is valuable for parsers that do their own domain-specific error handling, like language parsers, where parsing itself should never fail.

[randomeizer]

@stephencelis Yeah, that's true.