mietek / epigram2

Mirror of Epigram 2, by Conor McBride, et al.
https://code.google.com/p/epigram
MIT License
48 stars 7 forks source link

Label lookup resolution goes nuts under stress #82

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
By stress, I mean the bug 
[http://code.google.com/p/epigram/issues/detail?id=81]. However stressful this 
bug is, I don't think it should lead to such madness as this:

In a particularly bad setting (where parametric objects are mistakenly taken 
non-parametric by elim w/ motive), the label resolution code makes up a call to 
an object fully lambda-lifted, without discharging the spine of arguments.

This bug depending on another one, I would suggest that we ignore it till we 
fix the previous one. Then, we just keep in mind that there potentially is a 
mine in here.

(I'll push a test case and announce it here later on)

Original issue reported on code.google.com by pedag...@gmail.com on 5 Sep 2010 at 11:34

GoogleCodeExporter commented 9 years ago
I'm rewriting label search as part of my work on issue 70. Test cases would be 
useful.

Original comment by adamgundry on 6 Sep 2010 at 2:42

GoogleCodeExporter commented 9 years ago
Well, what I suspected happened: fixing bug #81 (or rather the lambda-lifting 
leak we mis-took for an elim w/ motive bug) 'solved' the problem. However, they 
clearly was a strange behavior, which one could explain by a broken invariant 
as well (in which case the warranty is void).

If you do want to track it down, rollback the fix 'Quick fix to higherMatch' 
and run James' lambda calculus example test/LambdaCalculus.pig.

However, I suspect it probably is saner to report this bug as WontFix and keep 
in mind there might be something lurking here. 

Original comment by pedag...@gmail.com on 6 Sep 2010 at 10:57

GoogleCodeExporter commented 9 years ago
Agreed.

Original comment by adamgundry on 8 Sep 2010 at 8:13