Two more interesting ideas.
Chris Pressey
11 months ago
| 93 | 93 | it's worth converting every possible way to the current "crude" |
| 94 | 94 | syntax (and it's almost certainly not worth handling these |
| 95 | 95 | expressions generally.) |
| 96 | * Once there are data structures in the context, one neat idea | |
| 97 | would be for some of those data structures to be | |
| 98 | [feature structures (Wikipedia)](https://en.wikipedia.org/wiki/Feature_structure), | |
| 99 | and the unification which currently occurs (in | |
| 100 | a truncated and efficient way) when a constraint is processed | |
| 101 | would be extended to include unification of feature structures. | |
| 102 | How _exactly_ this would work, and whether it would help for | |
| 103 | any practical purpose, remain to be seen, but it sounds like | |
| 104 | it would be an interesting experiment. | |
| 105 | * Once there are data types other than integers in the context, | |
| 106 | have two of the data types be terminals (that is, strings) | |
| 107 | and non-terminals (that is, names of productions), and allow | |
| 108 | these to be "reflectively" applied, so that the grammar can | |
| 109 | expect (or generate) a string non-terminal that it has computed | |
| 110 | at some earlier point. Even more interestingly, because | |
| 111 | non-terminals can take parameters, this leads to the possiblity | |
| 112 | of writing grammars in continuation-passing style, whatever | |
| 113 | that may be worth. | |
| 96 | 114 | * Allow "fuel" to be tracked, to ensure the storage is bounded |
| 97 | 115 | linearly to the amount of input. This aims to ensure that the |
| 98 | 116 | grammar is contained within PSPACE. |