Suggested approach to parse a 'vocabulary'?

[liscio]

Context

I am trying to parse functions with a similar syntax to Swift. Imagine the following toy example function definition:

measureDistance(to: {start,end}, using: {inches, centimeters, …}, percentAccuracy: [1-95])

An example call would look like this:

measureDistance(to: start, using: inches, percentAccuracy: 3)

Curly braces indicate enum values, and the square brackets represent an allowed range of values.

I have already captured much of the repetitive bits with my own Parser conformances, so each parser definition looks like this:

let measurementParser = Function("measureDistance") {
    Parse(MeasureCommand.measureDistance) {
        Parameter("to") { Boundary.parser() }
        Parameter("using") { Units.parser() }
        Parameter("percentAccuracy", isLast: true) { Int.parser() }
    }
}

Now let's assume I have 100 such functions defined. For now, I have such an arrangement working with nested OneOf parsers:

let commandParser = OneOf {
  OneOf {
  // ...
    OneOf {
      measurementParser
      conversionParser
      // ... another 4 here
    }
  // ...
}

It's gross, but it works. 😅

The Problem

The reported errors stink right now. When I mis-spell one of the commands, I am greeted by a massive error that lists all the commands:

1 |mesureDistance(to: start, using: inches, percentAccuracy: 3)
  |^ expected "measureDistance"
  |^ expected "convertUnits"
  |^ expected "reticulateSplines"
   ... // 97 more

Ideally, I'd like to surface something akin to Swift's own reporting:

  |^ Unrecognized function. Did you mean "measureDistance"?

How do I solve this?

I feel like there are a few possible ways forward here:

1. Wrap the nested OneOf parsers, and implement a try/catch to generate a better error. The trouble here is that I'd have to somehow figure out a way to "walk all the OneOf parsers" to find the Functions, and do the "spell-checking" using that list. Further, I'm not sure how I might inspect the ParsingError to decide when it's a spelling mistake, and not a legit Int.parser() failure—ParsingError is not public, unfortunately.
2. Somehow build an array of Function parsers in my own Parser conformance, but each thought along these lines so far has resulted in varied levels of wonkiness. Array of Anys that I force-cast to Function? maybe doing something using AnyParser and introspection, … ? I don't think either are possible due to the deeply-nested generics involved. Further, I don't think that you can replicate the nested try/catch blocks of OneOf with an arbitrary array.
3. Something long-winded, possibly requiring the help of a code generation tool. 🤮

Any tips on a workable solution would be great!

PS: Before anyone asks, I am not trying to implement/define a programming language using swift-parser. Instead, I'm only interested in one-shot commands. Imagine the target/action pattern from Cocoa(Touch), but the action carries specific parameter values. These actions need to be serialized, and are ideally human-readable. JSON/plist/etc representations would be far too nested, and highly awkward for a user to modify.

[stephencelis]

@liscio Some good thoughts here! A few immediate thoughts:

1. The nested OneOf situation will improve in 5.7, at the very least, where we'll be able to accept any number of parsers in a OneOf, no problem.
2. I think we'd like to finally make ParsingError public, but underscored. That will give folks an opportunity to leverage it in a caring way, knowing that the APIs may change in the future, and maybe give those same explorers the opportunity to improve the error handling of swift-parsing. Would this help unblock you to a certain extent?

[liscio]

@stephencelis The first item is nice to hear. I'm not quite aware of how the OneOf situation is improved by 5.7, though. Is it SE-0341, or something else that's been changed/fixed?

Regarding the exposure of ParsingError, that may help my chances. But I'm still not quite certain that my approach is sound—introspection into the nested list of parsers contained in a OneOf is where I am still likely to get hung up.

A new idea has since emerged since I last wrote. One that involves custom builders with their own inner equivalent to Parsers.OneOfMany—one that holds on to its list of supported keywords/parameters in a dictionary/array for the spell-checking bits.

I'll be sure to let you folks know if/when I end up with a workable solution—this project has been pre-empted a lot in the past week. 😛

[stephencelis]

@stephencelis The first item is nice to hear. I'm not quite aware of how the OneOf situation is improved by 5.7, though. Is it SE-0341, or something else that's been changed/fixed?

It's actually SE-0348, which will allow us to "infinitely" nest OneOf2s instead of overloading arity up to OneOf10.

[liscio]

Alright, I have determined a workable solution, and put together a repo to demonstrate the approach.

Here's what's neat about what I've done:

1. I parse String values to automatically generate each of the command parsers.
2. I store all the parsed-out command names in a hash table for (faster) lookup.
3. Because of 2, I can easily access these command names for spell-checked hints.