[query-parser] Make parsing find more efficient and produce better error messages #156

New issue

Open

opened 2020-08-06 16:55:53 +00:00 by gburd · 0 comments

gburd commented

2020-08-06 16:55:53 +00:00

(Migrated from github.com)

So this ticket tracks merging the new combine approach with the old BTreeMap approach, hopefully getting the performance and error handling advantages of the former with the pleasant combinatorial expression of the latter.

When I was pondering how to do this, I wondered about a macro that takes pairs of key-parser (or just keyword), value-parser with output types Value_1, ... ,Value_n and produces a typed tuple of fixed length n of type (Option<Value_1>, ..., Option<Value_n>). That gets around the heterogeneous return types while still allowing us to use parsers for the values.

There are two things at play here. In response to https://github.com/mozilla/mentat/pull/393#discussion_r109068152, this is definitely not the most efficient expression. In response to https://github.com/mozilla/mentat/pull/393#discussion_r109068301, it's really nice to parse the map values using `combine`. So this ticket tracks merging the new `combine` approach with the old `BTreeMap` approach, hopefully getting the performance and error handling advantages of the former with the pleasant combinatorial expression of the latter. When I was pondering how to do this, I wondered about a macro that takes pairs of key-parser (or just keyword), value-parser with output types `Value_1, ... ,Value_n` and produces a typed tuple of fixed length n of type `(Option<Value_1>, ..., Option<Value_n>)`. That gets around the heterogeneous return types while still allowing us to use parsers for the values.