I'd love to help with the conversion when I have a moment, but for now I suppose I could answer your questions.
In the transformation function, you'll need to rearrange those terms (in binary_op, maybe?). It's likely in yecc, you used a matchspec to do it. Something like this should work:
{binary_op, extract_line(Idx), list_to_atom(lists:nth(2,Node)), lists:nth(1,Node), lists:nth(3,Node)}
extract_line would look like so, of course (a good addition to the standard library):
extract_line({{line,Line},_}) -> Line.
Your grammar must be lacking an assertion of some sort that allows that to be an incomplete parse. In general, PEG parsers don't consume the whole input if a portion of is valid but the tail is not. Is "2+" a valid expression?
If not, you may need some disambiguation (i.e. ordered choice or factoring), or an EOI assertion (right now "!.", but I may introduce an EOI symbol) to register that as a syntax error.
{binary_op, extract_line(Idx), list_to_atom(lists:nth(2,Node)), lists:nth(1,Node), lists:nth(3,Node)}
I hope there's a better way to write transforms than this.`ifis_list(Node) ->[Left, Op, Right] = Node,{binary_op, line(Idx), list_to_atom(Op), Left, Right};true -> Nodeend`;
If not, you may need some disambiguation (i.e. ordered choice or factoring), or an EOI assertion (right now "!.", but I may introduce an EOI symbol) to register that as a syntax error.
Okay, let me see if I can figure out how to do this...
add_expr <- integer add_op add_expr / integerwould match "2+" if "PEG parsers don't consume the whole input if a portion of is valid but the tail is not"
FWIW, I tried your most recent grammar and got what seems to be correct results:
5> reia_parse:parse("2+").
{{integer,1,2},"+",{{line,1},{column,2}}}
Why not use case and take advantage of pattern matching?
Also, since you're wanting + and - to be atoms, you could push them down into that rule.
That rule looks fine. However, just for disambiguation, you might try putting parens around the first part of the choice.
That's an incomplete parse, of course. Internally, neotoma represents intermediate results as {Result, RemainingInput, NewIndex}, which is what it returned to you. So, what it parsed was "2", not "2+". It seems to me that you would need some kind of lookahead somewhere, but you might still come out with an incomplete parse. Another option is to introduce a semantic check in a rule at a higher level and throwing your own error.
Actually, I just thought of something. In some PEGs I've seen that have repetition or right-recursion
If so, that's quite easy for me to wire up, and I may even have a Reia shell with a Neotoma parser in a bit here...
Trying to allow an arbitrary number of separators between expressions, and for the last part of the input to be an arbitrary length sequence of separator tokens.expressions <- head:expr tail:(separator expr?)*`[{head, Head}, {tail, Tail}] = Node, [Head|[Expr || [_Separator,[_|_] = Expr] <- Tail]]`;
Well, if you're talking about a pure kleene star representation of what I'm trying to do, it looks like:
Actually that's an error saying it can't find the rule for 'add_op'. Do you have a syntax error in your grammar?