Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UnionMatcher doesn't add possible matches when throwing on ambiguity #3

Open
hugoduncan opened this issue May 31, 2012 · 4 comments
Open

Comments

@hugoduncan
Copy link

When the UnionMatcher throws due to ambiguous match, the possible matches are not added to the exception, which makes it harder than necessary to debug parsers for this case.

@cgrand
Copy link
Owner

cgrand commented May 31, 2012

Hugo how is the error message in the brand new Parsley v0.9.0 -- not great
I expect.

On Thu, May 31, 2012 at 6:31 PM, Hugo Duncan <
[email protected]

wrote:

When the UnionMatcher throws due to ambiguous match, the possible matches
are not added to the exception, which makes it harder than necessary to
debug parsers for this case.


Reply to this email directly or view it on GitHub:
#3

Professional: http://cgrand.net/ (fr)
On Clojure: http://clj-me.cgrand.net/ (en)

@hugoduncan
Copy link
Author

Looks like I get:

nth not supported on this type: Boolean
(def ambiguous-parser
  (parser
   :expr #{#"Abc" #"Ade"}))
(clojure.pprint/pprint (ambiguous-parser "A"))

Edit: Not sure what I was testing above...

@hugoduncan
Copy link
Author

0.9.0 reports the matcher functions that give ambiguous matches - is this what you intended?

I was expecting to see something like (pr-str (filter identity (map #(% s eof) matchers)))

@cgrand
Copy link
Owner

cgrand commented Jun 1, 2012

I reverted my modification and push a 0.9.1 out of the door (I should never commit in a hurry, even if I have to get off the train :-))

I don't know how to make the message more informative without more widespread changes: a successful matcher returns: the number of characters matched and the (usually) numerical id of the original matcher which are not that helpful when you have two conflicting regexes. Am I overlooking something there?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants