Think of difficult to parse programs

[alexschneider]

We're going to have to do a little bit of backtracking in our block parsing to ensure that we don't create ambiguity for something like:

y := 'bar'
baz := None
x := if y : foo = 'bar': baz = 'z' # we assign baz and x to 'z'

but it shouldn't be too hard - we may have to parse the "block" first, and then backtrack to parse the expression prior to the : beginning the "block". This is only a problem on single line expressions.

We're definitely going to need to think of gotchas and figure out ways to deal with them.

[rtoal]

I'd like to help but I'm a little confused.

Backtracking isn't a way to "avoid creating ambiguity." Either your grammar is ambiguous or it is not. To avoid having an ambiguous grammar, you should rewrite the grammar so it is not ambiguous. You can do this by (1) changing it around, or (2) using a PEG. If you want to live with the ambiguous grammar, then you have to write some informal rules on the side of the grammar to explain what the intended meaning is.

If you have ended up with an inherently ambiguous language then you should redesign it. Also consider a redesign if you find it too easy to construct WATs.

Consider whether you are overusing colons in your language. (Just my $0.02.)

[alexschneider]

Ambiguity probably wasn't the right word (and for that matter, perhaps neither was backtracking). Just goes to show what writing help wanted requests when you're not completely awake does.

The above will be parsed (from left to right) as:

vardec left='x', right=ifexp
ifexp condition="y : foo = 'bar'", body =varassign
varassign left=baz, right='z'

I'm leaving out a few steps and this is pretty informal, but I don't think this is ambiguous, just a little bit challenging to parse. I'm asking people to come up with more corner cases that are challenging to parse to ensure we get the right parse tree.

A PEG wouldn't be a bad idea though. You said that you were going to write a PEG for Iki or another language that it would be more suited for. It'd be helpful to see that, I think.

We also could talk about overusing colons - I'm open to using a different operator than ':=' for variable declarations, but I think that we should be able to work with this in the parser.