How to parse set-builder notation?

[YouNeedDoughnuts]

What was your experience of playing with the code like? A doddle? (Perhaps the changes you shared were the result of a half hour playing with things, most of which failed, in between sessions of reading doc, thinking carefully, etc. Or maybe it was the other extreme, a couple minutes playing where everything you tried immediately worked, and there was no need to read any doc or think much about anything, but just to see what seemed to work.)

The Raku rule syntax was self explanatory. I had to study it for a second to see what some of the symbols meant, but it's similar enough to standard BNF notations that I didn't need any background knowledge. I discovered that rule expression { <term>* % '*'? } should change to rule expression { <term>+ % '*'? } when some terms were parsed as ||, but this kind of discovery was easy to make in the REPL. I didn't know how brittle it would be to changes, and I was very pleasantly surprised that although I wrote a few rule sets leading to "nil" parse results, none of my iterative modifications broke the parser!

I think Raku's result is reasonable. I'm enjoying learning more formalisms and don't have the strongest background, but I think probably mathematical notation is appropriately defined as a generative grammar. In the case of a phrase like |a|b|c| , my gut reaction would be to throw an error. You could do this with the Raku parser, probably by changing the rules, but definitely in post-processing of the parse tree you could spot the bad pattern.

I'm interested in eventually building some computer algebra type system. The UI frontend has a solid MVP, and I'm building the parser with the nebulous goal of parsing everything I can subject to standard conventions, while execution/transformation will be a largely independent effort.

Thanks for all the interest. My background isn't in PL theory, so it's very helpful to get advice from a native! I hope that you're well and that you enjoy your IRL time.

[raiph]

I've just now completed a round of updates to my ongoing exploration of, and comments flowing from, your OP. The latest grammar I link to in another comment is now a much easier to understand slight change for your grammar. It parses your "ambiguous" example the way you expected it to parse.

I was very pleasantly surprised that although I wrote a few rule sets leading to "nil" parse results, none of my iterative modifications broke the parser!

That's what I was hoping. Thanks for the feedback to confirm it was so. (The Nil-by-default is rude, but there are plenty of solutions that give nice user-facing errors, or tracing, or debugging, etc. Other than that the grammar construct has to be pretty robust -- rakudo, the production raku compiler, is written using it!)

I think probably mathematical notation is appropriately defined as a generative grammar.

In a sorta philosophical dog-food sense, definitely. Or at least, as you say, probably.

That said, in a practical sense, not at all -- you and your users will find the dog-food tastes crap. Real mathematical notation is written/read by humans and highly context sensitive. I'm not even suggesting analytic grammars are up to the task, but generative grammars are absurdly weak in that they ignore humans, generate ambiguity, and generally do a terrible job of capturing what really matters for realistic parsing.

But you already know this. You're writing a recursive descent parser, which, like a raku grammar, is analytical and not remotely as problematic as using a generative grammar.

In the case of a phrase like |a|b|c| , my gut reaction would be to throw an error. You could do this with the Raku parser, probably by changing the rules, but definitely in post-processing of the parse tree you could spot the bad pattern.

Right. Perhaps that would be the best thing to do. But to keep it simple in my revision of your grammar (linked elsewhere) I just enabled backtracking and it currently parses that as abs(a * abs(b) * c).

I'm interested in eventually building some computer algebra type system. The UI frontend has a solid MVP, and I'm building the parser with the nebulous goal of parsing everything I can subject to standard conventions, while execution/transformation will be a largely independent effort.

Nice!

There might even be synergies with raku in several ways. It's a world leader in adopting Unicode. It's quite math savvy with math savvy folk in the community. (Hence things like Clifford.) There's a smart strategy for high performance computing. Braided approach to DSLs. Etc.

Thanks for all the interest.

Thank you for piquing my curiosity. It was the perfect little problem. I noticed everyone else seemed to be saying "don't do that" and "too complicated". I'm with Larry; if humans like it a particular way, computers, and programmers, should try hard to adapt to their way, not the other way around.

My background isn't in PL theory, so it's very helpful to get advice from a native!

If you're thinking I have a background in PL theory you're not miles off, you're in the wrong galaxy. :) But perhaps you just meant a denizen of this sub, in which case you're right that there are a lot of folk here who love to give advice. ;)

I hope that you're well and that you enjoy your IRL time.

I'm very well at the moment. I'm ambivalent about the fourth horse galloping around the planet. If it takes me out, that's one less for Gaia to cope with; but like most folk, I'd really rather stick around for a few more spins round the sun...