This expression is accepted:

1d20-5+2d6

While this one is rejected:

 1d20- 5  +  2d6

They are both valid, and should parse into the same tree.

Dice functions should be able to work with the resulting values from a previous function.

For example: roll 5 dice, take the higher 3, remove the lowest 1.

One of the dice groups may be marked. This serves for example for indicating the die that can cause a critical success.

The grammar should offer a way to mark this dice, in such a way that it is possible to know it's exact result (or the result of each die on the group) after the rolling process.

It should be noted that these dice may still be part of an algebraic operation, so for example you can roll a marked dice, along two unmarked one, get the result of the three dice added, and also get the exact result of the marked die.

Take into consideration that in the future it may be interesting having this dice be part of more than one operation.

For example, on one operation you add the marked die to two other dice, in another one you map the results of the marked die.

Currently there is a branch adding additional operators. But it doesn't apply precendence to multiplications and divisions.

This should be fixed at the grammar level.

Currently the grammar can't parse an expression like "-1", which contains only a single numeric value.

Note that negative numbers are valid when they are part of an expression such as "1-2".

The getFinalResult method is confusing, as it seems to be for the last value in the series.

Instead change it to getFinalResult or something similar.

Currently parsed grammars can only return integers. This means that divisions may not return the correct value.

For example '3/2' will return '1', not '1.5'.

The lexical rules on the grammar should be reviewed, as currently some possible lexical rules are mixed with the grammar ones.

The default rule is called function. This is confusing, and will be more once functions are added to the grammar.

Change it to "expression".

sometimes, though usually its rare, an RPG will ask for multiplication or division. Here is an example from the freely available "Basic Rules" of Dungeons & Dragons 5th Edition:

Starting Wealth

would you consider allowing multiplication (poss chars: x, *, ×) and division (poss chars: /, ÷) i personally prefer the charcaters * and /.

i would be willing to take a look at adding the necessary operation classes. I wanted to just bounce it off you first in case you have already ruled it out

The parser receives the input expression, applies the grammar and outputs the parsed tree.

This tree follows the interpreter pattern.

https://sourcemaking.com/design_patterns/interpreter

Which can be extended to allow the intrepreter to receive a strategy:

public <V> V interpret(Strategy<V> strategy);

This allows returning various values for the parsed result.

To ease this job the parser may returned a wrapper root node, containing the default interpretations, such as rolling the result.

Having this expression: "4d6+5".

• Rolls: 4, 5, 6, 4

There should be some way to print it neatly, which would look like: "[4 5 6 4] + 5".

The current ways to get values from a dice notation are too restrictive.

The default always returns an integer:

Integer roll = parsed.roll();

While using transformers is a bit clumsy:

Iterable<Dice> dice = parsed.transform(new DiceSetsTransformer());

Maybe the parser can be typed, and the return type can be defined by a transformer:

final DiceNotationExpressionParser<Iterable<Dice>> parser;
final Iterable<Dice> parsed;

parser = new DefaultDiceNotationExpressionParser<>(new DiceSetsTransformer());

parsed = parser.parse("1d6+12");

This would reduce the number of methods used to process the parsed notation.

Currently these are:

• roll
• transform
• parse

And they would be reduced to:

• parse

Currently expressions like "-1d6" are invalid.

Note that negative dice are valid when they are part of an expression such as "1d1-2d1".

To allow more control over complex operations the grammar should include support for parenthesis.

1+2*3=7
(1+2)*3=9

so the expression 5dz will throw an ANTRL NoViableAltException which is wrapped into a IllegalStateException however an expression like 6d6y will not throw an exception that i can handle. It seems that some error is thrown at some point in ANTLR because the logs contain

line 1:3 token recognition error at: 'y'

however there is no simple way for me to capture that error.

On the reports the grammar classes appear both on their folders and the base folder. Try to find out why this is happening and fix it.

To simplify the generated tree the subtraction operation can be replace with the addition operation.

After all, '1-2' is the same as '1 + -2'.

Functionality of retrieving the number of die, number of sides, operators used, and integers used in operations within the parsed variable would be extraordinarily useful to me. If there is some method in place of retrieving those variables please feel free to show how, as I'd like to use your parser in a discord bot that I am creating (with due credit, of course!)

This allows values like '-2'

Hi,
I try to use this librairy for a little game for my boy, but (maybe it already exists),
i can't find the way to have the detail of rolls
Ex : 1 want a 2D10 , if i to a .roll(), i'll have 15 for example.
But i would like to have a sorted list with 7 and 8 (7 for the first dire, 8 for the second)

How could i help you with this 'feature' ?

For example, imagine the case where the roll results have to be tweaked

https://github.com/antlr/grammars-v4

This repository includes several grammar examples.

Check the way these are defined and tested.

To ease the customization of parsed expressions there should be a quick way to get a stream traverser (preorder/postorder/inorder) which then can receive a lambda expression.

The grammar should not be called using the Antlr files, but with an implementation of the Parser interface.

The dice extractor is always taking the dice as positive values.

An expression like this:

1d6-2d8

Should return the second dice set as a negative value.

The grammar should reject notation using invalid whitespaces.

This for example should be rejected: "1 d6". But instead it is being parsed as if it were "1d6".

Add documentation about what the parse tree visitor is doing

The dice model may be better placed in its own model. Maybe even separated into an API and its implementation.

Rollers and similar functional classes would be included in the model?

Dice notation should include success and failure ranges if the chances for these should be calculated.

Some information which would help:

• Target value (and if the result should be equal, higher or lower)
• If instead of a target value this is a roll vs roll, then both rolls should be indicated
• Critical success/failure values (if they matter, as they do on roll vs roll)

Multiple dice groups could be supported.

They would be separated by commas: 1d6, 2d10+5

By default the number of sides should be 1, allowing dice without a defined number of sides.

So "d6" would be the same as "1d6".

It should be possible to check the results of a roll with a boolean operation.

For example: 2d6 > 3

If this is true and additional expression after the check would be executed.

The most common type of grammar supports normal dice, addition and substration.

One subset of the grammar should support only these operations.

Some lexer rules may be better defined as fragments, such as operator symbols.

fragment ADD
:
   '+'
;

fragment SUB
:
   '-'
;

This may help with the token collision which appear sometimes when attempting changes.

Right now the grammar accepts dice with zero dice, while the model does not.

This should be corrected, setting the minimum value for sides as one.

For example:

• Repeat the highest value (every 6 in any d6)
• Ignore the lowest/highest value
• Keep the lowest/highest value

These rules are applied to the parsed expression. So they should be applied with transformers.

But maybe they can be activated through special keywords in the grammar, which would require an extension of the basic grammar.