notes.md


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

# one-of in parallel
## Problem
When in a one-of block, it's harder to tell where an error came from.

## Current solution
We have critical blocks that stop parsing when the parser inside fails.

## Problem with current solution
We need to be dilligent in placing critical blocks.

## Another approach
We could take a page from LR parsers and instead of driving the parsing from the parsers themselves we invert the flow, making the input drive the parsing. This results in a breadth first parsing, where the one-of block parses one step of every of it's children and decides which to keep. In the event there's only one children left, it is critical, so a failure stops parsing and reports the error.

## How to select between BF and DF when parsing
Add an extra argument to parser type (lambda (input)) for the parsing mode.
one-of will be BF and comp will be DF.
This means that the immediate children of a one-of block will be parsed step by step.

## Implementing BF in bind
Instead of calling the resulting function with the input, return it.
It will be the caller's responsibility to call the resulting lambda with the appropiate input.
This will give control to the one-of block to call the next parsing step.

# lazy binding
## Problem
If defining a parser that surrounds another, the inner parser must know about what the delimiter parser is attempting to parse, specially after the inner parser.

## Solution
Implement lazy binding. This sweeps the next parser across the input until it finds where it first parses, then takes the distance from the current input and calls the current parser with a limit on how much input to parse equal to said difference.

# TODO
* Change the parser entry so that it takes streams as input. This will make it easier to interact with other packages.
* Change literal parser into a macro that chains unit parsers. This will take advantage of the BF feature in one-of block.