Mark, 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 believe with some carefully applied heuristics (programmable in Avail?) the diagnostics system can be even further fine-tuned. Great stuff! cheers, Robbert. > On 03 Mar 2015, at 17:17, Mark van Gulik <[email protected]> wrote: > > I'll look into the specific problem you're encountering. > > We wholeheartedly agree that the new compiler needs some work on its error > reporting. It doesn't even capture line numbers yet, so stack traces > (almost) always say a function occurred on line 0 of some module. We also > lost diagnostic information that was specific to the core Avail syntax, so > we're working out completely new schemes to reintroduce diagnostic > information of comparable quality to the old compiler, but in a > syntax-neutral way. > > The big plus with the macro compiler is that the core syntax can now be > *subtracted* from DSLs. So if the Quizmaster syntax shouldn't let you define > variables and blocks and whatever, well, just don't import the core syntax > macro names and the end user simply can't do it. We're rewriting the Wumpus > example in dialects of Avail that strongly resemble existing programming > languages, and once that's done we're going to rebuild the front page to > highlight this new ability. > > Todd has already been sweeping through the library, converting for loops to > use a syntax (via macros) that avoids declaring a block argument for the > counter. Next will be the condition blocks for a chained else-if, making > Boolean logic operations short-circuited without square brackets, etc. he > already has the $foo and $"foo" notations looking up atoms at compile time > (otherwise the module in which to start the lookup is wrong). He updated the > library to get rid of kludgey module constants that hold these atoms, since > it's much nicer to just use the new forms of $foo instead. > > I'm working on rewriting the phrase type scheme so they're covariantly > parameterized by their subexpression types, not just by the type of value > that they will yield when executed. Then you can talk about a list of > constants, or a local variable that's initialized by a constant three-digit > integer less than 450, where the variable name starts with the characters > "norge" and contains no other English vowels. > > Todd already changed the stable method declaration mechanism to replace > applications to constants with a folded version, not just semantically > restricting the result to that particular single value. Level two would > already do that eventually, but this way tools like the debugger won't be > tempted to pointlessly trace through execution of "complex literal" > expressions like {1,2}, <10>[1], "fu"++"bar", (1<<12)-2^8, or 15m•s^-1. > > > On Mar 3, 2015, at 9:14 AM, Robbert van Dalen <[email protected]> wrote: > >> Mark, >> >> I’m afraid I cannot (yet) appreciate what you’ve accomplished with the >> introduction of macros. >> But I am very eager to learn! >> >> Using the bleeding edge repo I’ve noticed that the compiler’s diagnostic >> messages have become less user friendly. >> Here is an example: >> >> Method "_add_" is >> [ >> a : number, >> b : number >> | >> a + b >> ] : number; >> >> Method "_square_" is >> [ >> a : number, >> b : number >> | >> a add b × a add b >> ] : number; >> >> Method "test m1" is >> [ >> 2 square 3 >> ]; >> >> Expression a add b × a add b is ambiguous, and I believe the ‘non-macro’ >> compiler reported exactly that. >> But with the macro in, the compiler reports the following: >> >> >>> 18: Method "_square_" is >> >>> 19: [ >> >>> 20: a : number, >> >>> 21: b : number >> >>> 22: | >> >>> 23: a add b × a add b >> >>> 24: ] : number; >> >>> 25: >> >>> 26: ⤷ Method "test m1" is >> >>> 27: [ >> >>>--------------------------------------------------------------------- >> >>> Expected... >> >>> variable "Method" to have been declared before use >> (file="/examples/Tutorial/M1", line=26) >> >> ?? >> >> cheers, >> Robbert. >> >>
signature.asc
Description: Message signed with OpenPGP using GPGMail
