craff / pacomb Goto Github PK

The simplest approach is to collect terminal names at the position of the error. On problem is
that we have to do it when the test the accepted charset too.

Removing empty and all later phase is only useful on a left branch of a grammar containing left recursion. As this makes the grammar and actions more complex, we should do it only in that case.

Here is the failing regexp "\([ \r\t\026]\|\(\(#[^\n]\)\)"

See comment in lib/hashtbl_eq.ml

The following comment seems wrong.

By adding a charset or parametrized by the expected value in
continuation we should be able to use an exact charset for dependent sequence.

This might impact performance a bit for grammar not using dependent sequence, but we could
have two variants of the Comb module, with the same interface, selected automatically or not.

This would give the following type for continuation:

type ('a, 'b) cont = Charset.t * ('b env -> 'a -> Charset.t * ('b err -> 'b))

or

type ('a, 'b) cont = Charset.t * ('a -> Charset.t * ('b env -> 'b err -> 'b))

instead of the current

type ('a, 'b) cont = Charset.t * ('b env -> 'a -> 'b err -> 'b)

This way we can get the charset without evaluating the continuation to the end.

Hi,

I just ported a whole parser using pacomb and it is very nice. One thing that I don't understand well is how to deal with ambiguity. Specifically, the merge function is attached to the %parser declaration, so as I understand it, the whole file is parsed, and then ambiguities are resolved; but this can already be made using parse_all_buffer. What I would prefer to do is to resolve ambiguites locally, i.e. being able to attach merge function to rules, but I could not find how to do that. The only thing I found is partial_parse_buffer, but I don't think using directly would work correctly.

Is there a way to solve this problem? Maybe by adding a and%parser rule suffices?

Try " (2" in calc_ext error is reported at 2...

This would ensure linear time and constant space for non ambiguous grammars that
do not use dependent sequences (with dependent sequence, no hope to predict anything, that's clear).

A problem is to store in input table from Input the result of the terminal to apply it only once at each position. As a grammar may have a lot of terminal (But only a few used at one position ?), it would require to move container to a Log complexity using hashtbl. As we have to record both success and failure of terminals, there might be a dozen of terminals or even more at one position.

This might be a bit slower that charset, but the stability and predactibility in complexity is
much more important than a constant factor. And we can still keep charsets as a pretest ...
but this is not a good idea for issue #9.

May be one needs to have more grammars using Pacomb to test before choosing.

Probably two combinators: test_before and test_after.
tests will be lost if applied to a grammar parsing the empty input. Is this a problem ?
Should this trigger an error ?

Or let tu user use dseq as this is not very common?

Too many positions are lost resulting in bad type errors. This must be considered a bug.

EKey and ELr are not printed

May be this is natural. Indeed, the position of empty is not well defined, is it before or after the blank... in the middle ;-)

I is very annoying to work with buf and pos all the time. Do we actually gain anything on the side of efficiency with that?