Follow

Ok, grammar draft number I-don't-want-to-think-about-it.

I wonder how feasible it would be to allow ternary comparison expressions to test for ranges e.g. 3 < x < 5 rather than having to use 2 separate expressions. Normally, 3 < x reduces to a boolean, then the other comparison fails.

Guess I'm adding a RangeCompEx

Show thread

... or not, that would *really* break normal comparison expressions and make the grammar ambiguous:

a > b > c -> ((comp a b) c) || (rangecomp a b c)

Could be either, but parsers like to reduce early, so I'd get the first.

Thinking I'll implement that logic in the semantic analyser *after* the , so I still get the feature.

Show thread

var x = if ( cond ) {
someexpr ;
} else {
someotherexpr ;
}

Should there be a semicolon after the if/else? What about here?

var x = someval | someexpr | complicatedshit | if ( cond ) {
someexpr ;
} else {
someotherexpr ;
}

I think the former shouldn't, but the latter should. This is where it gets weird though:

var x = class.member.member.statement ( expr ) {
body ;
}

Semicolon?

Show thread

Going to say all 3 should have a semicolon, but if you were to remove the "var x =" from the start so it's just the statement call, then only the second one should. This then makes designing the syntax easier.

Show thread

Holy shit. First time since I started redoing this that the has broken, but *not* because it can't actually parse properly.

This time it was a range error...

Show thread

Oh for fuck's sake.

Type with a type arg:
a < b >
Comparison expression:
a < b

Show thread

Ok, new syntax for type arguments. Could steal 's syntax for templates, which would make the type arguments look like this:

a!(b)

Could work. Will try.

Show thread

Didn't work rip. It gets passed it, but it never actually reduces the type arguments, so it just carries on until an inevitable "unexpected blah at blah".

Show thread

Oooooohhhhhh. The range expression gets reduced early. Fuck. So that means it's seeing the '<' and thinking "oh this is in a CompEx so I'll reduce the RangeEx and carry on" which of course is wrong, and it's failing at the ',' because it thinks it's building an Expression in parentheses, which of course don't contain commas.

So if I switch the precedence of RangeEx and CompEx, or just not allow one directly within the other, then that particular case should be sorted... right?

Show thread

Ok, we're closer. Now it's dying at the '<', which means it's successfully realising it's not a CompEx, but also means it's bad because it's not building the TypeArgs, which is really suspicious because it's already in the middle of a type when it fails...

Show thread

The type is reducing early...

I wonder what would happen if I modded the LALR generator so whenever it goes to overwrite a shift with a reduce, it just doesn't...

Show thread

HA. Of course that works. So now I have a greedy parser, which is good because it gets further, but also still a broken parser because it tries to build a fucking expression rather than method parameters *again*.

Show thread

See, now I'm just slowly turning it back into a GLR parser...

I wonder if it would be easier if rather than try and progress everything in lockstep, it just did depth-first traversal. Because if the grammar is only slightly ambiguous, most routes die quickly.

Show thread

Ok, what's making this really tedious to write is I'm spawning new parser threads in 2 different and completely unrelated places, but I can't merge them because they're reached at different points through the process.

1. When we move to the next token.
2. When we've just reduced a rule and are following the GOTO after it.

So I need some way of spawning new parser threads with a starting action, then I guess I could just iterate through all of them.

Show thread

<will smith voice>Yaaaahhhh, it's rewrite time</will smith voice>

I regret typing that...

Show thread

Wew. Progress. I now have a . Problem though is that - as you should be expecting by now - it doesn't work. What's reassuring though is that it's getting as far as the got, so it must be working to an extent. It's just a matter of making sure every action is present, and I think I know where to start with that (transition table).

Show thread

Hmm. Ok so it's not in the transition table. At no point are members of the table being overwritten. So the issue is coming from elsewhere...

Time for more logging I guess...

Show thread

Ok I'm really confused now.

The *only* thing that can be something in parentheses with no possible comma in the middle is a PrimaryEx -> '(' Expression ')', so that's what the is dying in.

We *must* be in a PostfixEx because of what's been reduced recently (a PostfixEx, which can be formed of PostfixEx MethodParams for instance), and a comma should be in the follow set of the PostfixEx currently reduced, which should reduce up to an Expression and then to a MethodParam, but that's not happening.

Show thread

Ok, going to commit and push what I have so far because I haven't done that in $too_long.

Show thread
Show more

@OTheB will Smith voice on seeing your commit history oh that's hot, that's hot

Show more
Sign in to participate in the conversation
Mastodon for Tech Folks

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!