> Writing parsers, which I do a lot, requires very little parsing theory...
I am currently writing an Earley parser. When I'm done, you will indeed need little math to use it. However, I had to grasp several non-trivial mathematical insights to write this damn tool (most notably graph search). And I'm not even done: currently, my parser only handle grammars like this:
A -> B C D
A -> B 'x' E
B ->
etc.
I want to handle the full Backus Naur Form, however, so I will need to compile BNF grammars down to a set of production rules. This will involve things very close to lambda lifting, which is rooted in lambda calculus.
Math is the main activity in writing this parser. The code is merely a formalization of such math.
I believe the result will be worthwhile: the error handling should be just as good as manual recursive descent parsing (RDP). Parsing code using my framework should be about 10 times as short as RDP. It will not be limited to LL grammars, unlike RDP. And you will still need very little math to write a parser —just like RDP. But that's because I will have abstracted it under the rug.
---
I don't know what kind of compilers you write, but I'm surprised to hear you say math is not the main activity. We're talking about semantic-preserving transformations here, how could it not be math?
Or, you already know all the math, and applying it doesn't feel like "math" any more.
I do Bret Victor style interactive programming environments. I've developed a set of tricks over the years and they are all quite simple. It really is programming in the classic sense and not so much Greek symbols on the whiteboard.
also, what I do is not very well understood, so there is no good theory for it yet and a lot of open questions to investigate. So its more experiment and measure vs. find a proof that will tell you for sure the right thing to do.
> I've developed a set of tricks over the years and they are all quite simple.
Actually, so is Earley parsing. The more I study this little piece of CS, the more I see how simple this really is. This is why it feels so much like math to me: hard at the beginning, then something "clicks" and everything becomes simpler.
Your "set of tricks" are probably similar. Knowing nothing about them, I'd bet their simplicity is rooted in some deep, abstract, yet simple math, just waiting to be formalized:
> what I do is not very well understood, so there is no good theory for it yet and a lot of open questions to investigate.
And how do you plan to further your understanding, or finding good theories? It can't be just psychology and cognitive science. I'm sure there will be some math involved, including proofs.
My set of tricks is more like: trace dependencies for work as it is done, put work on dirty list when dependency changes, redo work, + some tricks to optimize previous steps. It is really hard to interpret that as math, especially if the word "math" is to remain meaningful and useful. It is all math at some level, but so is everything.
I am currently writing an Earley parser. When I'm done, you will indeed need little math to use it. However, I had to grasp several non-trivial mathematical insights to write this damn tool (most notably graph search). And I'm not even done: currently, my parser only handle grammars like this:
I want to handle the full Backus Naur Form, however, so I will need to compile BNF grammars down to a set of production rules. This will involve things very close to lambda lifting, which is rooted in lambda calculus.Math is the main activity in writing this parser. The code is merely a formalization of such math.
I believe the result will be worthwhile: the error handling should be just as good as manual recursive descent parsing (RDP). Parsing code using my framework should be about 10 times as short as RDP. It will not be limited to LL grammars, unlike RDP. And you will still need very little math to write a parser —just like RDP. But that's because I will have abstracted it under the rug.
---
I don't know what kind of compilers you write, but I'm surprised to hear you say math is not the main activity. We're talking about semantic-preserving transformations here, how could it not be math?
Or, you already know all the math, and applying it doesn't feel like "math" any more.