You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi there. I figured this was better as a discussion since it isn't an issue with Parlot per-se.
So I have a math/dice expression parser that was written by me in C++ that I was converting to C# to use within a Discord bot, and in the process, I decided to have a look at other parser generators and parser combinators as potential replacements. I found that Parlot is faster and uses less memory than my own solution, so I'm currently considering replacing my parser with Parlot. But there were a few things I wanted to see if they were possibly with Parlot or not.
The main thing to point out is that my parser took input that had no whitespace, so I settled on using Parlot's Literals instead of Terms.
Firstly, in my parser, I would preprocess the input, so that a lone % becomes 1d100, any dX (where X is a number) that is found without a number before it gets an implicit 1 placed before it (so if I did something like d6+1 it would be treated like 1d6+1 and if I did 1+d6 it would be treated like 1+1d6, as examples), and it would add in *s to handle implicit multiplication. The last one isn't that important to me, but the other two, I'm wondering if Parlot could handle this on its own or if I'd still need to preprocess the input or not. I'd rather not have to preprocess the input, because that implies knowing what tokens are what ahead-of-time (so I'd need to know what characters are operators, what characters are numbers, what characters are constants, etc.). Technically, it also had to convert what it assumed were unary minus signs into another character (I used _) so that I could handle it properly in the shunting-yard algorithm later, but I find I don't need to do that with Parlot due to how it handles the expressions.
The next thing my parser did was check the "fixed" expression. It basically checked for function calls being invalid (basically missing the open parenthesis), checking to make sure commas and operators had valid characters before and after them, and making sure that parentheses were placed in proper spots, and it would report on exactly where that happened, as well as if an unexpected character was encountered. The best I've been able to do with Parlot is to let me know when I hadn't closed an open parenthesis, when my primary expression (which is a number, a function call, a grouped expression or a constant) hasn't been satisfied and when I get to the end of the line unexpectedly (like if I did 1+2) for instance). I'm wondering if that is enough to cover the problems. I also technically put an ElseError on my unary expression, but I don't think it would ever actually get hit?
After that I tokenize my input by injecting spaces between everything so that the shunting-yard algorithm knows what to do, but obviously I don't need that since Parlot handles that.
I use Parlot to create class instances that inherit ultimately from a base class, and each class instance has an Evaluate() method, with the ones for numbers and constants giving out a concrete value and all others evaluating a nested expression. This works quite well in comparison to taking the postfix notation received from the shunting-yard algorithm and parsing that, plus with Parlot, I am more able to define how my function calls work, so I can specifically say that some functions only allow for one argument and some allow for 2 arguments and some allow for 2+ arguments.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi there. I figured this was better as a discussion since it isn't an issue with Parlot per-se.
So I have a math/dice expression parser that was written by me in C++ that I was converting to C# to use within a Discord bot, and in the process, I decided to have a look at other parser generators and parser combinators as potential replacements. I found that Parlot is faster and uses less memory than my own solution, so I'm currently considering replacing my parser with Parlot. But there were a few things I wanted to see if they were possibly with Parlot or not.
The main thing to point out is that my parser took input that had no whitespace, so I settled on using Parlot's Literals instead of Terms.
Firstly, in my parser, I would preprocess the input, so that a lone
%
becomes1d100
, anydX
(where X is a number) that is found without a number before it gets an implicit1
placed before it (so if I did something liked6+1
it would be treated like1d6+1
and if I did1+d6
it would be treated like1+1d6
, as examples), and it would add in*
s to handle implicit multiplication. The last one isn't that important to me, but the other two, I'm wondering if Parlot could handle this on its own or if I'd still need to preprocess the input or not. I'd rather not have to preprocess the input, because that implies knowing what tokens are what ahead-of-time (so I'd need to know what characters are operators, what characters are numbers, what characters are constants, etc.). Technically, it also had to convert what it assumed were unary minus signs into another character (I used_
) so that I could handle it properly in the shunting-yard algorithm later, but I find I don't need to do that with Parlot due to how it handles the expressions.The next thing my parser did was check the "fixed" expression. It basically checked for function calls being invalid (basically missing the open parenthesis), checking to make sure commas and operators had valid characters before and after them, and making sure that parentheses were placed in proper spots, and it would report on exactly where that happened, as well as if an unexpected character was encountered. The best I've been able to do with Parlot is to let me know when I hadn't closed an open parenthesis, when my primary expression (which is a number, a function call, a grouped expression or a constant) hasn't been satisfied and when I get to the end of the line unexpectedly (like if I did
1+2)
for instance). I'm wondering if that is enough to cover the problems. I also technically put anElseError
on my unary expression, but I don't think it would ever actually get hit?After that I tokenize my input by injecting spaces between everything so that the shunting-yard algorithm knows what to do, but obviously I don't need that since Parlot handles that.
I use Parlot to create class instances that inherit ultimately from a base class, and each class instance has an
Evaluate()
method, with the ones for numbers and constants giving out a concrete value and all others evaluating a nested expression. This works quite well in comparison to taking the postfix notation received from the shunting-yard algorithm and parsing that, plus with Parlot, I am more able to define how my function calls work, so I can specifically say that some functions only allow for one argument and some allow for 2 arguments and some allow for 2+ arguments.Mainly, I'd like input to see if what I've done is good for replacing my previous parser. For reference, my original parser is located primarily starting here: https://github.com/CyberBotX/DiceServ/blob/7b260e254e011113f03cd46b1168f2d5e44a9825/diceserv.cpp#L673 and below is what I am planning to do with Parlot.
Beta Was this translation helpful? Give feedback.
All reactions