From 325606aff6b74eac8d21f02359159cc2eeb4befa Mon Sep 17 00:00:00 2001 From: John Hyde Date: Sat, 26 Oct 2024 21:03:07 -0700 Subject: [PATCH 1/9] correct definition of `hair` --- content/language/hoon/guides/parsing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/language/hoon/guides/parsing.md b/content/language/hoon/guides/parsing.md index e956132..7696884 100644 --- a/content/language/hoon/guides/parsing.md +++ b/content/language/hoon/guides/parsing.md @@ -100,7 +100,7 @@ A `hair` is a pair of `@ud` used to keep track of what has already been parsed for stack tracing purposes. This allows the parser to reveal where the problem is in case it hits something unexpected during parsing. -`p` represents the column and `q` represents the line. +`p` represents the line and `q` represents the column. ### `nail` From f6bed9cf969d3e8f505c27b2d481943a0790f0c3 Mon Sep 17 00:00:00 2001 From: John Hyde Date: Sat, 26 Oct 2024 21:06:02 -0700 Subject: [PATCH 2/9] correcting definition of `edge` --- content/courses/hoon-school/Q2-parsing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/courses/hoon-school/Q2-parsing.md b/content/courses/hoon-school/Q2-parsing.md index 9d31c9a..5a2a5d1 100644 --- a/content/courses/hoon-school/Q2-parsing.md +++ b/content/courses/hoon-school/Q2-parsing.md @@ -41,7 +41,7 @@ we have to wade directly into a sea of new types and processes. To wit: - A `hair` is the position in the text the parser is at, as a cell of column & line, `[p=@ud q=@ud]`. - A `nail` is parser input, a cell of `hair` and `tape`. -- An `edge` is parser output, a cell of `hair` and a `unit` of `hair` +- An `edge` is parser output, a cell of `hair` and a `unit` of `*` and `nail`. (There are some subtleties around failure-to-parse here that we'll defer a moment.) - A `rule` is a parser, a gate which applies a `nail` to yield an From f2a3458559f2a2a450ff9d4d13077e8fc1df5a6c Mon Sep 17 00:00:00 2001 From: John Hyde Date: Sat, 26 Oct 2024 22:18:26 -0700 Subject: [PATCH 3/9] correcting implied definition of `hair` parts --- content/courses/hoon-school/Q2-parsing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/courses/hoon-school/Q2-parsing.md b/content/courses/hoon-school/Q2-parsing.md index 5a2a5d1..0513853 100644 --- a/content/courses/hoon-school/Q2-parsing.md +++ b/content/courses/hoon-school/Q2-parsing.md @@ -39,7 +39,7 @@ we have to wade directly into a sea of new types and processes. To wit: - A {% tooltip label="tape" href="/glossary/tape" /%} is the string to be parsed. - A `hair` is the position in the text the parser is at, as a cell of - column & line, `[p=@ud q=@ud]`. + line & column, `[p=@ud q=@ud]`. - A `nail` is parser input, a cell of `hair` and `tape`. - An `edge` is parser output, a cell of `hair` and a `unit` of `*` and `nail`. (There are some subtleties around failure-to-parse here From 70649d9c9b74977ac91bfd6c989a5d79a622bad3 Mon Sep 17 00:00:00 2001 From: John Hyde Date: Sat, 26 Oct 2024 22:26:39 -0700 Subject: [PATCH 4/9] Update parsing.md with accurate wings for parts of an `edge` --- content/language/hoon/guides/parsing.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/language/hoon/guides/parsing.md b/content/language/hoon/guides/parsing.md index 7696884..f57ffc2 100644 --- a/content/language/hoon/guides/parsing.md +++ b/content/language/hoon/guides/parsing.md @@ -134,9 +134,9 @@ of the original input `tape `up to which the text has been parsed. If parsing failed, `p` will be the first `hair` at which parsing failed. `q` may be `~`, indicating that parsing has failed . -If parsing did not fail, `p.q` is the data structure that is the result of the -parse up to this point, while `q.q` is the `nail` which contains the remainder -of what is to be parsed. If `q` is not null, `p` and `p.q.q` are identical. +If parsing did not fail, `p.u.q` is the data structure that is the result of the +parse up to this point, while `q.u.q` is the `nail` which contains the remainder +of what is to be parsed. If `q` is not null, `p` and `p.q.u.q` are identical. ### `rule` From 63a8b653a75cd593a733d45371cde2faa55e7446 Mon Sep 17 00:00:00 2001 From: John Hyde Date: Sat, 26 Oct 2024 23:00:12 -0700 Subject: [PATCH 5/9] attempt to get close the lid on the can of worms, re: using the `u` face in `edge` wings --- content/language/hoon/guides/parsing.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/language/hoon/guides/parsing.md b/content/language/hoon/guides/parsing.md index f57ffc2..7696884 100644 --- a/content/language/hoon/guides/parsing.md +++ b/content/language/hoon/guides/parsing.md @@ -134,9 +134,9 @@ of the original input `tape `up to which the text has been parsed. If parsing failed, `p` will be the first `hair` at which parsing failed. `q` may be `~`, indicating that parsing has failed . -If parsing did not fail, `p.u.q` is the data structure that is the result of the -parse up to this point, while `q.u.q` is the `nail` which contains the remainder -of what is to be parsed. If `q` is not null, `p` and `p.q.u.q` are identical. +If parsing did not fail, `p.q` is the data structure that is the result of the +parse up to this point, while `q.q` is the `nail` which contains the remainder +of what is to be parsed. If `q` is not null, `p` and `p.q.q` are identical. ### `rule` From c4fab06c0dcc385e1bd9697fc869e7e5faa78636 Mon Sep 17 00:00:00 2001 From: John Hyde Date: Sat, 26 Oct 2024 23:08:49 -0700 Subject: [PATCH 6/9] Update parsing.md to correct some edge wings --- content/language/hoon/guides/parsing.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/language/hoon/guides/parsing.md b/content/language/hoon/guides/parsing.md index 7696884..a72b640 100644 --- a/content/language/hoon/guides/parsing.md +++ b/content/language/hoon/guides/parsing.md @@ -173,7 +173,7 @@ We note that `p.edg` is `[p=1 q=2]`, indicating that the next character to be parsed is in line 1, column 2. `q.edg` is not null, indicating that parsing succeeded. `p.q.edg` is `'a'`, which is the result of the parse. `p.q.q.edg` is the same as `p.edg`, which is always the case for `rule`s built using standard library functions when parsing succeeds. Lastly, -`q.q.edg` is `"bc"`, which is the part of the input `tape` that has yet to be parsed. +`q.q.q.edg` is `"bc"`, which is the part of the input `tape` that has yet to be parsed. Now let's see what happens when parsing fails. @@ -208,7 +208,7 @@ Let's see what happens when we successfully parse the entire input `tape`. line 1, column 4. Of course, this does not exist since the input `tape` was only 3 characters long, so this actually indicates that the entire `tape` has been successfully parsed (since the `hair` does not advance in the case of failure). -`p.q.edg` is `'abc'`, as expected. `q.q.edg` is `""`, indicating that nothing +`p.q.edg` is `'abc'`, as expected. `q.q.q.edg` is `""`, indicating that nothing remains to be parsed. What happens if we only match some of the input `tape`? From 142d0fb451e2badad129db9aafbce9c4624e1561 Mon Sep 17 00:00:00 2001 From: John Hyde Date: Thu, 31 Oct 2024 12:05:06 -0700 Subject: [PATCH 7/9] Update parsing.md to remove inconvenient but accurate u= --- content/language/hoon/guides/parsing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/language/hoon/guides/parsing.md b/content/language/hoon/guides/parsing.md index a72b640..5cb1150 100644 --- a/content/language/hoon/guides/parsing.md +++ b/content/language/hoon/guides/parsing.md @@ -267,7 +267,7 @@ is `%foo`. ``` > ((cold %foo (just 'a')) [[1 1] "abc"]) -[p=[p=1 q=2] q=[~ u=[p=%foo q=[p=[p=1 q=2] q="bc"]]]] +[p=[p=1 q=2] q=[~ [p=%foo q=[p=[p=1 q=2] q="bc"]]]] ``` One common scenario where `+cold` sees play is when writing [command line From 6b68aa4122c72c11a89324cc99e0b5e38d39f96c Mon Sep 17 00:00:00 2001 From: John Hyde Date: Fri, 1 Nov 2024 06:07:20 -0700 Subject: [PATCH 8/9] Apply suggestions from code review Co-authored-by: tinnus-napbus <77721746+tinnus-napbus@users.noreply.github.com> --- content/courses/hoon-school/Q2-parsing.md | 2 +- content/language/hoon/guides/parsing.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/content/courses/hoon-school/Q2-parsing.md b/content/courses/hoon-school/Q2-parsing.md index 0513853..e4e8a66 100644 --- a/content/courses/hoon-school/Q2-parsing.md +++ b/content/courses/hoon-school/Q2-parsing.md @@ -41,7 +41,7 @@ we have to wade directly into a sea of new types and processes. To wit: - A `hair` is the position in the text the parser is at, as a cell of line & column, `[p=@ud q=@ud]`. - A `nail` is parser input, a cell of `hair` and `tape`. -- An `edge` is parser output, a cell of `hair` and a `unit` of `*` +- An `edge` is parser output, a pair of a `hair` and a unit containing a pair of the result and a `nail` and `nail`. (There are some subtleties around failure-to-parse here that we'll defer a moment.) - A `rule` is a parser, a gate which applies a `nail` to yield an diff --git a/content/language/hoon/guides/parsing.md b/content/language/hoon/guides/parsing.md index 5cb1150..ccca10a 100644 --- a/content/language/hoon/guides/parsing.md +++ b/content/language/hoon/guides/parsing.md @@ -173,7 +173,7 @@ We note that `p.edg` is `[p=1 q=2]`, indicating that the next character to be parsed is in line 1, column 2. `q.edg` is not null, indicating that parsing succeeded. `p.q.edg` is `'a'`, which is the result of the parse. `p.q.q.edg` is the same as `p.edg`, which is always the case for `rule`s built using standard library functions when parsing succeeds. Lastly, -`q.q.q.edg` is `"bc"`, which is the part of the input `tape` that has yet to be parsed. +`q.q.u.q.edg` is `"bc"`, which is the part of the input `tape` that has yet to be parsed. Now let's see what happens when parsing fails. @@ -208,7 +208,7 @@ Let's see what happens when we successfully parse the entire input `tape`. line 1, column 4. Of course, this does not exist since the input `tape` was only 3 characters long, so this actually indicates that the entire `tape` has been successfully parsed (since the `hair` does not advance in the case of failure). -`p.q.edg` is `'abc'`, as expected. `q.q.q.edg` is `""`, indicating that nothing +`p.u.q.edg` is `'abc'`, as expected. `q.q.u.q.edg` is `""`, indicating that nothing remains to be parsed. What happens if we only match some of the input `tape`? From d73030eb82bf9703fb7cd194145d3a055982347a Mon Sep 17 00:00:00 2001 From: John Hyde Date: Fri, 1 Nov 2024 06:24:15 -0700 Subject: [PATCH 9/9] Update parsing.md to properly use u face on units --- content/language/hoon/guides/parsing.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/content/language/hoon/guides/parsing.md b/content/language/hoon/guides/parsing.md index ccca10a..0066713 100644 --- a/content/language/hoon/guides/parsing.md +++ b/content/language/hoon/guides/parsing.md @@ -134,9 +134,9 @@ of the original input `tape `up to which the text has been parsed. If parsing failed, `p` will be the first `hair` at which parsing failed. `q` may be `~`, indicating that parsing has failed . -If parsing did not fail, `p.q` is the data structure that is the result of the -parse up to this point, while `q.q` is the `nail` which contains the remainder -of what is to be parsed. If `q` is not null, `p` and `p.q.q` are identical. +If parsing did not fail, `p.u.q` is the data structure that is the result of the +parse up to this point, while `q.u.q` is the `nail` which contains the remainder +of what is to be parsed. If `q` is not null, `p` and `p.q.u.q` are identical. ### `rule` @@ -171,7 +171,7 @@ of the input `nail`. We note that `p.edg` is `[p=1 q=2]`, indicating that the next character to be parsed is in line 1, column 2. `q.edg` is not null, indicating that parsing -succeeded. `p.q.edg` is `'a'`, which is the result of the parse. `p.q.q.edg` is the same as `p.edg`, which is always the case for +succeeded. `p.u.q.edg` is `'a'`, which is the result of the parse. `p.q.u.q.edg` is the same as `p.edg`, which is always the case for `rule`s built using standard library functions when parsing succeeds. Lastly, `q.q.u.q.edg` is `"bc"`, which is the part of the input `tape` that has yet to be parsed. @@ -219,10 +219,10 @@ What happens if we only match some of the input `tape`? [p=[p=1 q=3] q=[~ [p='ab' q=[p=[p=1 q=3] q="c"]]]] ``` -Now we have that the result, `p.q.edg`, is `'ab'`, while the remainder `q.q.q.edg` +Now we have that the result, `p.u.q.edg`, is `'ab'`, while the remainder `q.q.u.q.edg` is `"c"`. So `+jest` has successfully parsed the first two characters, while the last character remains. Furthermore, we still have the information that the -remaining character was in line 1 column 3 from `p.edg` and `p.q.q.edg`. +remaining character was in line 1 column 3 from `p.edg` and `p.q.u.q.edg`. What happens when `+jest` fails? @@ -267,7 +267,7 @@ is `%foo`. ``` > ((cold %foo (just 'a')) [[1 1] "abc"]) -[p=[p=1 q=2] q=[~ [p=%foo q=[p=[p=1 q=2] q="bc"]]]] +[p=[p=1 q=2] q=[~ u=[p=%foo q=[p=[p=1 q=2] q="bc"]]]] ``` One common scenario where `+cold` sees play is when writing [command line