-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
As suspected, Delaney's grammar was stalling during tapecalc, during the getTapesDefault stage of getTapesQualified. The issue seems to be that getTapesDefault sums all the tape sets to get the tape set of the whole Qualified collection... but with 80+ symbols, many of them with quite complex tape/vocab structure, summing all that can take a long time. (At least I think that's what the slowdown was, it's possible there's also a slowdown due to other factors.) But there's nothing we DO with that sum, it's semantically erroneous to care what the tapes of a collection or qualified are, they're epsilons. Their tape/vocab structure should be empty literals. (I had a comment from the tapecalc refactoring era at the return, saying "TODO: This return is semantically incorrect, fix this someday.") However, fixing this breaks some tests -- specifically, the ones illustrating some of the most convoluted cursor/match/embed structures, and even THEN they didn't break during normal execution, only during runTests. But these are important tests, illustrating the most difficult situation for vocab resolution to get right, so we can't just comment them out as solved. It turns out what's going wrong is that, due to the randomness of the keys generated by mergeKeys, the two "runs" of tapeCalc (initial and updated) result in different vocab maps each time. But Embeds get their tapes and maps from the env's symbol table, which comes from the first run, so in the second run they can end up with different vocab structures than the things they're referencing. (This is rare, but that's why this is coming up in those tricky merge/cursor tests, those are the ones whose vocabulary is determined solely by means of this machinery.) Why does this come up in runTests but not in generation? Well, in these tests we select Default, but in runTests we select All. All embeds Default, but due to this issue ends up with a different symbol table. (So it's not ultimately due to anything about runTests, it's just that this is what revealed the deeper bug.) (Why did the incorrect semantics of getTapesQualified hide this bug? Because summing all these different symbols merges their vocab maps, meaning that the resulting map contains both tapecalc stages' keys.) There's no number of extra tapecalc runs that could address this issue -- the contents of the env's symbol table will always be that of the previous run. So instead, we have to make it so that the first and the second run always agree on the vocab map keys -- that they not be random each time. One (rejected) idea from earlier is to just name merged keys after their "parent" keys, like merging t1 and t2 into "$t1___t2" or something. I rejected this originally because this violates the independent naming of tapes (e.g. that there might be different t1s, and this doesn't handle them separately); that was the whole reason for redoing tapecalc in the first place! However, I'm hard pressed to think of a good example of how this could cause things to go wrong, in a realistic grammar. It's not like if we take cursor t1 inside another cursor t1, then merge them both with t2, that we would get incorrect vocab leakage between the t1s. (I mean, we would get a shared vocab, but it wouldn't be incorrect -- they would share their vocabulary by virtue of the fact that both of them merged with t2.) We'd have to have two different t1s and two different t2s, and for each t1 to be related to its t2 in the convoluted structure seen in these tests, then both closed off with cursors and the results summed. Anyway, I think this kind of theoretical vocab leakage is a less bad bug than throwing a key error due to embeds and their referents using different vocab maps! So it's "$t1___t2" for now until we think of something better.
- Loading branch information
Showing
9 changed files
with
71 additions
and
19 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters