{"push_id":755201018,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"a4b3c6f5462386c916db83a7f0ec68aae022f67b","before":"ef44f50bee098de759c913a479f8ba96a4c1d18f","commits":[{"sha":"a4b3c6f5462386c916db83a7f0ec68aae022f67b","author":{"email":"f5f25150104e445be281fa3e96f4d2bf3a8cb24c@runbox.com","name":"Zoltan Somogyi"},"message":"Simplify the code that makes some items abstract for interfaces.\n\ncompiler/comp_unit_interface.m:\ncompiler/write_module_interface_files.m:\n    Each of these modules have code that decided which items to include\n    in interface, either in their original form, or abstracted. Both pieces\n    of code used to executed three switches in sequence on the same item.\n    The overall effect was the composition of the three switches, but\n    readers of the code had to do this composition in their head\n    if they wanted to understand the code.\n\n    Replace both three-switch sequences with a single switch, mainly to make\n    the effect of the code immediately obvious to the reader, and to eliminate\n    the dead code we used to have, when an earlier switch (the first, or\n    maybe second) decided the outcome, and it didn't matter what the later\n    (maybe the second, definitely the third) switches did.\n\n    The new code does fewer tests, but allocates more memory. The net\n    performance effect seems to be a wash. (In two different speed tests,\n    I got one speedup and one slowdown. Strangely, eliminating the extra\n    memory allocation led to slowdown.)\n\n    There are enough differences between how these two modules make their\n    decisions that I don't see a useful way to factor out the commonalities\n    in their needs.\n\ncompiler/item_util.m:\n    Replace the utility predicates needed by the three-switch approach\n    with the ones needed by the new single switch approach.","distinct":true,"url":"https://api.github.com/repos/Mercury-Language/mercury/commits/a4b3c6f5462386c916db83a7f0ec68aae022f67b"}]}