feature: constraint validation of production parse result about earley HOT 7 OPEN

Hey!

Yeah, I think you're right that this isn't possible with the current interface. Would you like to contribute this feature?

from earley.

Heh... I might, but I am a beginner in Haskell and your code looks like Chinese to me now. :) And it would take a time to me. If you gave some hints what parts need to be modified, it might be easier to dive in.

from earley.

Is that what you need to add "keyword parsing" to a parser? For example, I want to write a little expression parser, but my AST has let..in, along with alphanumeric variable names. I don't want Var "let" to be a valid parse, but I can't see anyway to express that in Earley at the moment.

Edit: I guess the alternative is an explicit tokenisation phase.

from earley.

No, I need it for another purpose, but in your case it can be useful too if you have a list of keywords. Examples of what I want to use it for: limiting the range of an integer if I want to read a part of IP-address or a port number. Or to verify that the "IP/mask" has the correct IP with host bits set to zero. Or the range - is correct (number1 <= number2).

from earley.

Oh sorry, I was being a bit selfish - I meant to say would I need this requested feature for my purpose! I am trying to use Earley on a stream of Chars and don't want to parse let as Var "let". If I were in a monadic parser setting, I could use guard, but that's not an option as we're limited to Applicative. Your suggestion is like guard :: Bool -> m a, but would be more like filterProd :: (a -> Bool) -> Prod r e t a -> Prod r e t a, and I would be able to define identifier <- rule $ filterProd (notElem [ "let", "in" ]) (many (satisfy isAlphaNum)).

Edit: I thought this was done in #47, but that's something different. I should stop posting on GitHub near midnight...

from earley.

Just an update on this: I moved to an explicit tokeniser instead and no longer need this.

from earley.

I wonder if this could be generalized to Filter :: ([a] -> [b]) -> Prod r e t a -> Prod r e t b, where this disambiguation function could filter the list. This would also enable generating a parse tree, rather than a list of all flat parses, i.e. pushing disambiguation towards the leaves. For example disambiguate d = Filter (pure . d)

from earley.