| 1 | |
|---|
| 2 | |
|---|
| 3 | As of 2008-Mar-06, src/perl6/STD.pm is the closest thing we currently |
|---|
| 4 | have for a "real", authoritative grammar for p6. This directory has |
|---|
| 5 | tools related to it. |
|---|
| 6 | |
|---|
| 7 | * STD_extract |
|---|
| 8 | |
|---|
| 9 | Intended to pull information out of STD.pm. It took the approach of a |
|---|
| 10 | piece by piece "parse", which makes it bitrot rapidly as STD changes. |
|---|
| 11 | It provided moderately useful information, but focus shifted elsewhere |
|---|
| 12 | before the quality of its output was very high. |
|---|
| 13 | |
|---|
| 14 | * STD_red (elsewhere) |
|---|
| 15 | |
|---|
| 16 | A version of STD.pm hand translated to ruby. It was intended to be a |
|---|
| 17 | relatively low risk, but high manual effort, attempt to get a usably |
|---|
| 18 | working p6 parser. |
|---|
| 19 | |
|---|
| 20 | * STD_deconstructed |
|---|
| 21 | |
|---|
| 22 | Is the beginning of a fallback strategy. When it looked like actually |
|---|
| 23 | understandly the contents of STD.pm might prove necessary, rather than |
|---|
| 24 | simply relying on its being correct, a much more analytic approach |
|---|
| 25 | than STD_red was needed. |
|---|
| 26 | |
|---|
| 27 | It takes the information in STD.pm, and organizes it for use by parser |
|---|
| 28 | implementers. Sync'ing with STD.pm requires extracting any _ideas_ |
|---|
| 29 | which have changed, and changing STD_deconstructed. So unattended, |
|---|
| 30 | STD.pm and STD_deconstructed will tend to diverge. But "cease to |
|---|
| 31 | function due to bitrot" need not be a problem. |
|---|
| 32 | |
|---|
| 33 | Why not STD_extract? STD_extract is too fragle in the face of STD.pm |
|---|
| 34 | editing. Given the role it would have here, keeping it updated isn't |
|---|
| 35 | going to happen. A less fragile, paragraph and rough sorting match, |
|---|
| 36 | approach to scraping STD.pm, to help keep STD_deconstructed in sync, |
|---|
| 37 | does seem worthwhile. |
|---|
| 38 | |
|---|
| 39 | Motivation for creation (2008-Mar-05): The plan was once to get a |
|---|
| 40 | bootstrap parser from STD_red or rakudo or redsix. redsix became less |
|---|
| 41 | attractive because of the increased appeal of working with a "real" |
|---|
| 42 | grammar, and because it turned out to require some development effort, |
|---|
| 43 | which as throw away code, it was begrudged. rakudo turned out to have |
|---|
| 44 | more parsefails than expected, and the hope that if blockers turned |
|---|
| 45 | up, they would get fixed, began to seem questionable. Leaving just |
|---|
| 46 | STD_red. So when one of its design assumptions became iffy - that |
|---|
| 47 | STD.pm represented "abstractly" working code, which in so far as it |
|---|
| 48 | had problems, would get fixed, so STD_red could cleave closely to |
|---|
| 49 | STD.pm, without attending to grammar design, and only worry about it's |
|---|
| 50 | own tranlation errors - it seemed worth sketching out what a fallback |
|---|
| 51 | strategy would look like. |
|---|
