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

support for failure object return when no match can be found #2

Open
carocad opened this issue May 4, 2016 · 1 comment
Open

support for failure object return when no match can be found #2

carocad opened this issue May 4, 2016 · 1 comment

Comments

@carocad
Copy link

carocad commented May 4, 2016

Hey Christophe,
first of all thanks for the great library. My attempt to follow Russ Cox implementation sadly isn't as elegant as good as yours. I was wondering if you are planning or thinking of implementing a failure object as a return value instead of 'nil'.

This goes in the lines of 'instaparse' where if the input doesn't match the parser description then a failure object is returned indicating at which point did the match process fail and what was expected.

Something like:

parse failed with input 'hello-word'
                         ^^^^
Expected any of:
- chao
- return

I would also be willing to work on this in case you are quite busy. I have some basic understanding of how the algorithm works but I have yet to understand your full implementation, some guidance tips would be very helpfull.

So far I guess that the change should be done in these lines:

            (reduce (fn [threads pc]
                      (let [[op arg] (nth insts pc)
                            registers (ctxs pc)]
                        (case op
                          :pred (if (arg x)
                                  (add-thread threads (inc pc) (cons idx xs) registers insts)
                                  threads))))

But I'm confused about your use of the 'run' function in the loop for the longest match :/

@cgrand
Copy link
Owner

cgrand commented May 17, 2016

I can't tell for sure I would make such behavior the default but as an option it could be ok.

run consumes several items until either an accept or failed state is reached. longest-match calls run until either the input is consumed or a failed state is attained. The last accept state is returned (which by definition is the accept state of the longest match).

Currently I'm working on lookaheads (negative lookahead is done and works but I'm not happy with the impl – I want to try a stack of vm instead).

One other thing I'd like to explore is turning instructions into a fn (with combinators not with macros).

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

No branches or pull requests

2 participants