Effort to merge some pull requests
francoisthire opened this issue · comments
It would be interesting to dedicate some effort to merge pull requests so that tools around Dedukti can be used on the master branch:
I think that all these PR should be merged eventually but probably some problems need to be addressed first.
- For #99 , documentation is missing
- For #141, even if it does not implement precisely the semantics you want @Gaspi I think we could merge this PR and do another PR for the semantics you want
- For #190 @Gaspi from what I recall, I fixed the point you raised. However, you will probably disagree about the use of advanced features. Is it possible to still merge this PR first, and do a second PR which enhance the kernel or the API with something simpler? Interoperability tools are based upon this PR and going backward is a little bit late now.
- For #203 , Is it possible to have a link to the benchmarks? This PR complexifies somehow the codebase also, I am not sure whether the new stuff is properly documented.
Is it possible for the people mentioned here to spend like an afternoon, or even a day to merge these PRs? I think it is becoming urgent to merge these PRs.
Below is a table of the last benchmark acu-state vs master. They are a bit old but the code base didn't move too much since.
| commit_date | commit | branch | compilation | dk-tests | dklib | examples | libraries | matita | matita_factorial |
|---|---|---|---|---|---|---|---|---|---|
| 05/12/19 | 851cf22 | acu-state | 7,9166666667 | 5,4883333333 | 0,24 | 6,5154545455 | 1016,6318181818 | 179,4072727273 | 1511,58 |
| 03/12/19 | 3e572f4 | master | 7,2925 | 4,975 | 0,2318181818 | 6,0327272727 | 647,9318181818 | 149,0772727273 | 1303,83 |
Overall there is a cost to having AC rewriting
- in terms of type-checking time, even when files that do no rely on this feature.
- in terms of code complexity. I could add some comments but I doubt it will ever be easily understandable. It's possible that this feature should be optional (compilation flags) in order to keep a "minimal, trustable" core.
@Gaspi : Do you think it would be possible (in an easy way of course) to have two binaries where one is compiled with acu and one without so that we postpone this time issue? This way, we can merge this PR so that you don't need to maintain a fork. Maybe this will introduce a little bit of code duplication, but it might be an intermediate step before we find a better solution?
Would you agree to rename private to protected to be coherent with lambdapi?
Not relevant anymore.