From 34ccc296b6265be09501917fe3deae89549edaf4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Juan=20Manuel=20Tom=C3=A1s?= Date: Wed, 9 Oct 2024 15:56:45 -0300 Subject: Implement bind sweep --- notes.md | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) (limited to 'notes.md') diff --git a/notes.md b/notes.md index 9eddec5..03ea43e 100644 --- a/notes.md +++ b/notes.md @@ -1,22 +1,26 @@ -# Problem +# one-of in parallel +## Problem When in a one-of block, it's harder to tell where an error came from. -# Current solution +## Current solution We have critical blocks that stop parsing when the parser inside fails. -# Problem with current solution +## Problem with current solution We need to be dilligent in placing critical blocks. -# Another approach +## 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 +## 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 +## 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. -- cgit v1.2.3