It works, however, this is rather inefficient: it has a loop parsing the integers one by one, building a typelist and then it loops over this typelist to summarise the result. Using template metaprograms in your applications can have a serious impact on the compiler's memory usage and the speed of the compilation, therefore I recommend being careful with these things.

Metaparse offers more efficient ways of achieving the same result. You don't need two loops: you can merge them together and add every number to your summary right after parsing it. Metaparse offers the foldl for this.

With foldl you specify:

Our parser can be implemented this way:

using better_sum_parser = foldl<int_token, mpl::int_<0>, sum_op>;

As you can see the implementation of the parser is more compact. Here is a diagram showing what happens when you use this parser to parse some input:

As you can see, not only the implementation of the parser is more compact, but it achieves the same result by doing less as well. It parses the input by applying int_token repeatedly, just like the previous solution. But it produces the final result without building a typelist as an internal step. Here is how it works internally:

It summarises the results of the repeated int_token application using sum_op. This implementation is more efficient. It accepts an empty string as a valid input: the sum of it is 0. It may be good for you, in which case you are done. If you don't wan to accept it, you can use foldl1 instead of foldl. This is the same, but it rejects empty input. (Metaparse offers repeated1 as well if you choose the first approach and would like to reject empty string)

	Note
	Note that if you are reading this manual for the first time, you probably want to skip this section and proceed with Introducing foldl_start_with_parser

You might have noticed that Metaparse offers foldr as well. The difference between foldl and foldr is the direction in which the results are summarised. (l stands for from the Left and r stands for from the Right) Here is a diagram showing how better_sum_parser works if it is implemented using foldr:

As you can see this is very similar to using foldl, but the results coming out of the individual applications of int_token are summarised in a right-to-left order. As sum_op is addition, it does not affect the end result, but in other cases it might.

	Note
	Note that the implementation of foldl is more efficient than foldr. Prefer foldl whenever possible.

As you might expect it, Metaparse offers foldr1 as well, which folds from the right and rejects empty input.

Let's change the grammar of our little language. Instead of a list of numbers, let's expect numbers separated by a + symbol. Our example input becomes the following:

BOOST_METAPARSE_STRING("11 + 13 + 3 + 21")

Parsing it with foldl or repeated is difficult: there has to be a + symbol before every element except the first one. None of the already introduced repetition constructs offer a way of treating the first element in a different way.

If we forget about the first number for a moment, the rest of the input is "+ 13 + 3 + 21". This can easily be parsed by foldl (or repeated):

using plus_token = token<lit_c<'+'>>;
using plus_int = last_of<plus_token, int_token>;

using sum_parser2 = foldl<plus_int, int_<0>, sum_op>;

It uses plus_int, that is last_of<plus_token, int_token> as the parser that is used repeatedly to get the numbers. It does the following:

This way last_of<plus_token, int_token> returns the value of the number as the result of parsing, just like our previous parser, int_token did. Because of this, it can be used as a drop-in replacement of int_token in the previous example and we get a parser for our updated language. Or at least for all number except the first one.

This foldl can not parse the first element, because it expects a + symbol before every number. You might think of making the + symbol optional in the above approach - don't do that. It makes the parser accept "11 + 13 3 21" as well as the + symbol is now optional everywhere.

What you could do is parsing the first element with int_token, the rest of the elements with the above foldl-based solution and add the result of the two. This is left as an exercise to the reader.

Metaparse offers foldl_start_with_parser to implement this. foldl_start_with_parser is the same as foldl. The difference is that instead of an initial value to combine the list elements with it takes an initial parser:

using plus_token = token<lit_c<'+'>>;
using plus_int = last_of<plus_token, int_token>;

using sum_parser3 = foldl_start_with_parser<plus_int, int_token, sum_op>;

foldl_start_with_parser starts with applying that initial parser and uses the result it returns as the initial value for folding. It does the same as foldl after that. The following diagram shows how it can be used to parse a list of numbers separated by + symbols:

As the diagram shows, it start parsing the list of numbers with int_token, uses its value as the starting value for folding (earlier approaches were using the value int_<0> as this starting value). Then it parses all elements of the list by using plus_int multiple times.

	Note
	Note that if you are reading this manual for the first time, you probably want to skip this section and try creating some parsers using foldl_start_with_parser instead.

foldl_start_with_parser has its from the right pair, foldr_start_with_parser. It uses the same elements as foldl_start_with_parser but in a different order. Here is a parser for our example language implemented with foldr_start_with_parser:

using plus_token = token<lit_c<'+'>>;
using int_plus = first_of<int_token, plus_token>;

using sum_parser4 = foldr_start_with_parser<int_plus, int_token, sum_op>;

Note that it uses int_plus instead of plus_int. This is because the parser the initial value for folding comes from is used after int_plus has parsed the input as many times as it could. It might sound strange for the first time, but the following diagram should help you understand how it works:

As you can see, it starts with the parser that is applied repeatedly on the input, thus instead of parsing plus_token int_token repeatedly, we need to parse int_token plus_token repeatedly. The last number is not followed by +, thus int_plus fails to parse it and it stops the iteration. foldr_start_with_parser then uses the other parser, int_token to parse the input. It succeeds and the result it returns is used as the starting value for folding from the right.

	Note
	Note that as the above description also suggests, the implementation of foldl_start_with_parser is more efficient than foldr_start_with_parser. Prefer foldl_start_with_parser whenever possible.

Using a parser built with foldl_start_with_parser we can parse the input when the input is correct. However, it is not always the case. Consider the following input for example:

BOOST_METAPARSE_STRING("11 + 13 + 3 + 21 +")

This is an invalid expression. However, if we parse it using the foldl_start_with_parser-based parser presented earlier (sum_parser3), it accepts the input and the result is 48. This is because foldl_start_with_parser parses the input as long as it can. It parses the firstint_token (11) and then it starts parsing the plus_int elements (+ 13, + 3, + 21). After parsing all of these, it tries to parse the remaining " +" input using plus_int which fails and therefore foldl_start_with_parser stops after + 21.

The problem is that the parser parses the longest sub-expression starting from the beginning, that represents a valid expression. The rest is ignored. The parser can be wrapped by entire_input to make sure to reject expressions with invalid extra characters at the end, however, that won't make the error message useful. (entire_input can only tell the author of the invalid expression that after + 21 is something wrong).

Metaparse provides foldl_reject_incomplete_start_with_parser, which does the same as foldl_start_with_parser, except that once no further repetitions are found, it checks where the repeated parser (in our example plus_int) fails. When it can make any progress (eg. it finds a + symbol), then foldl_reject_incomplete_start_with_parser assumes, that the expression's author intended to make the repetition longer, but made a mistake and propagates the error message coming from that last broken expression.

The above diagram shows how foldl_reject_incomplete_start_with_parser parses the example invalid input and how it fails. This can be used for better error reporting from the parsers.

Other folding parsers also have their f version. (eg. foldr_reject_incomplete, foldl_reject_incomplete1, etc).

As you might have noticed, there are a lot of different folding parser combinators. To help you find the right one, the following naming convention is used:

	Note
	Note that there is no foldr_reject_incomplete_start_with_parser. The p version of the right-folding parsers applies the special parser, whose result is the initial value, after the repeated elements. Therefore, when the parser parsing one repeated element fails, foldr_start_with_parser would apply that special final parser instead of checking how the repeated element's parser failed.