Robbert, > I’ve just fetched the latest master with your new parse failure code. > The diagnostics are much better now. > At default, there are now 4 possible failure positions to look into. > That makes perfect sense with Avail’s free syntax.
I wholeheartedly agree. When I was coding the first non-primitive macros, the diagnostics were terrible. I am only a little ashamed to say that I actually lost my temper and screamed profanities at my computer after being stuck on the same problem for 8 hours. The new diagnostics would have caught the problem right away, so I’m going to call them a huge win. The compiler is somehow managing to parse beyond semicolons (which each statement macro ends with), which is both computationally expensive and also annoying when you’re trying to figure out what you did wrong. Mark is looking into this problem. When it’s resolved, I believe that our diagnostics will be better than they ever have been. Mark has also designed a strategy for augmenting the compiler's bipartite rendezvous mechanism to parallelize argument type checking alongside parse instruction execution. Up to the present time, the compiler has only checked the types of arguments at message boundaries. This new mechanism could simultaneously speed up parsing and improve diagnostics. > I believe with some carefully applied heuristics (programmable in Avail?) the > diagnostics system can be even further fine-tuned. Yes, I want something like that too. So far, I have written the overwhelming volume of actual Avail code, and I can attest that the user’s “Reject parse,expected:_” invocations from semantic restrictions (and now macros) are virtually always more cogent in diagnosing a problem than the generic messages emitted by the compiler — if you see one of these messages, then it’s almost always (85%) the reason why something failed. So I’d like to be able to specify that these message have priority over messages produced by the system. Todd
