From 45aab75f5351e843430399030c27a13cd7edea2e Mon Sep 17 00:00:00 2001 From: NeilBrown Date: Wed, 10 Mar 2021 17:07:53 +1100 Subject: [PATCH] updates --- twod | 119 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 119 insertions(+) diff --git a/twod b/twod index 4c9a44e..251f794 100644 --- a/twod +++ b/twod @@ -3577,3 +3577,122 @@ ifstatement -> ifhead iftail | iftail casehead -> case expr block + +24feb + Hmmm. awkwardness. + An ifpart can be "if expr then simple ;"... no it cannot... + But the problem was that some forms for a head with an optional tail + must end EOL, other forms need not. + But the whole must end EOL. + + So: do we put EOL at end of 'statement' or end of IfSuffix + + Let's try assuming it is at the end of 'statement' + So IfSuffix can assume an EOL follows + So CondStatement can too + So an ifhead either 'may' or 'must' be followed by an EOL. + If may, it is followed by IfSuffix which is empty, or starts OptEOL + If must, it is followed by empty or + No.. this isn't working for me. + + Let's try assuming that a CondStatement ends with an EOL. + So an IfSuffix must too. and it cannot be just EOL + If an ifhead that must be followed by EOL, it is either EOL or EOL IfSuffix + If it may be, then EOL or IfSuffix + + + ForPart ThenPart SwitchPart are ALWAYS followed by something, so can end + EOL or not, as suits + WhilePart IfPart CasePart might be the last thing so each option must + end with a SuffixEOL which ends with EOL or SuffixOpt which might not + + What do I want to do about + : SimpleStatements + + It is useful for + case value : statement + and maybe even + if cond : statement + though for the latter I can and use 'then'. + For 'else' I don't need the ':', but it wouldn't hurt. + + Problem is: do I insist on a trailing newline or ';' + If I don't then + case foo: bar case bar: baz + would be legal, but hard to read, as would + if cond : stat1 else stat2 + which is probbly error prone. + + But do I want + switch expr + case val1: st1 + case val2: st2 + else: st3 + + That looks like an indented block, but is really indented lines. + So it is probably a mistake. + So allow switch expr : or ';' at the end + + Whatever happens after "switch expr" must work after "while expr block" + + So.... + If first case is not indented, none of them may be + If first is: it happens in an IN/OUT block, so again all the same + + Can I implement that? Can I have IN after a non-terminal somehow? + When I see an IN, I could reduce as long as go_to_cnt == 0. + That might help after an OUT, but not after EXPR,, + + Or: look at next symbol. If it can be shifted, we ignore the IN. + If not, we reduce and try to shift the IN again. + + Also: need to mark IN as ignored when popped off during error recovery, + and maintain stack when discarding during error recovery + +26feb2021 + Syntax for blocks? + { IN statements OUT } + { simplestatements } + : IN Statements OUT + + but what about + : simplestatements NL .... or ';' + + In other contexts I have + for simple; statements; then simple ; statements ; while expr: + + I currently require a ';' or newline before "then" or "while" + + Interesting other cases are: + + case expr : simplestatements + while expr : simplestatements + + For 'if' I currently have "if expr then simplestatements" + + Because of 'for' and 'then' I don't want to require ':' before simplestatements. + I could have + while expr do simplestatements + But what do I do for 'case' ??? I really want the ':' there. + So I should use it for 'if' and 'while' + 'for' could be followed immediately by IN, as could then and even if/while + So the ':' comes after an expression. + +27feb2021 + Problems with the idea of only using : to come after an expression. + 1/ "else" looks wrong compared to Python, but may I can get used to that + 2/ with "for" it would be simple statements, with "while" it would be expr + if there was no indent. Do I need different things to look different? + If statements always follow ':', the "for" and "then" always need a ':' + for: a=1; then: a = a+1; while a < 10: + + In C there is no difference, but I want a difference.. + +03mar2021 + Arg... I'm not struggle with parsing concepts this time, I'm struggling with code. + I want to add an "EOL" symbol to the grammar as a special terminal. + It is like "NEWLINE", but handled a bit differently. + + In parsergen it is just another terminal symbol, but it mustn't get added + to the "known" list. Currently all terminals from TK_reserved are added + to "known". Maybe if I give it a number that is after the virtual symbols -- 2.43.0