By the way, the second item would have detected the "field2 : number;” as a duplicate module variable declaration in the problem Robbert submitted on February 26th (or already the 27th in Europe?). That was the issue where there were semicolons instead of commas in a class declaration. Now the second occurrence of field2 is where it reports that field2 was already defined as a module variable.
> On Mar 10, 2015, at 5:35 PM, Mark van Gulik <[email protected]> wrote: > > I just checked in code that should improve the diagnostics significantly. > Commit note: > > -The macro compiler no longer parses beyond ";". This improves error > reporting. > -Now reports duplicate module variables/constants. > -Nested macros now respect grammatical restrictions properly. > -Other minor improvements to error reporting. > -"_†" parsing no longer directly consumes a token, but expects a variable use > phrase instead. > > I also checked in the beginning of some work that recursively describes why a > particular simple expression (or other simple parse) was being requested at a > specific token in the parse. It needs more work before it’ll be useful, > however. > > > >> On Mar 6, 2015, at 4:18 PM, Todd L Smith <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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 >
signature.asc
Description: Message signed with OpenPGP using GPGMail
