agda-categories icon indicating copy to clipboard operation
agda-categories copied to clipboard

ramp up stdlib version?

Open HuStmpHrrr opened this issue 2 years ago • 14 comments

The current release is 1.7.2.

HuStmpHrrr avatar Apr 12 '23 15:04 HuStmpHrrr

Yep, definitely should do. Not sure when I'll get time, right now is scarily busy for me.

JacquesCarette avatar Apr 13 '23 06:04 JacquesCarette

At least from my testing, the library type-checks fine with the newer Agda and stdlib versions. #372 is a simple PR to update the requirements, I didn't know what to do with the README since it refers to the latest release.

jpoiret avatar May 02 '23 12:05 jpoiret

I think we can make a small release to match the agda and stdlib version?

HuStmpHrrr avatar May 02 '23 12:05 HuStmpHrrr

Yes, we can. @HuStmpHrrr if you have the time to do it, please do so. I may not get to it until late this week.

JacquesCarette avatar May 02 '23 17:05 JacquesCarette

I will wait for the change of the PR and then we are good to go.

HuStmpHrrr avatar May 02 '23 18:05 HuStmpHrrr

If you never use cubical, you can stick to 1.7.1, which uses --without-K instead of --cubical-compatible and is thus 20% faster to build. If agda-categories, do you use --without-K or --cubical-compatible? (Or just vanilla (implicit) --with-K?)

andreasabel avatar May 09 '23 08:05 andreasabel

@andreasabel once the stdlib is fully built, --cubical-compatible doesn't have a performance impact on users of the library, right?

jpoiret avatar May 09 '23 09:05 jpoiret

agda-categories still uses --without-K (and safe). We should also add --exact-split, but that is almost always a no-op.

JacquesCarette avatar May 09 '23 11:05 JacquesCarette

@andreasabel once the stdlib is fully built, --cubical-compatible doesn't have a performance impact on users of the library, right?

Not if you have unlimited memory with O(1) access. ;-)
Seriously, I have not benchmarked, but --cubical-compatible generates extra definitions and extra clauses, and these reside in memory, so I am positive about some impact, even though I cannot put a number to it.

andreasabel avatar May 10 '23 20:05 andreasabel

Do I understand correctly that it's not possible to import agda-categories (which uses --without-K) from a --cubical module in Agda 2.6.3? This used to be possible in 2.6.2.

ncfavier avatar May 14 '23 14:05 ncfavier

That is correct: https://agda.readthedocs.io/en/v2.6.3/language/cubical-compatible.html#cubical-compatible

Note that code that uses (only) --without-K can not be imported from code that uses --cubical.

So yes, switching to Agda 2.6.3 without bumping --without-K to --cubical-compatible will be a regression, as the library is not usable anymore from --cubical then.

I should retreat my suggestion until we have an easy way (e.g. via library-wide flag) to bump a --without-K library to --cubical-compatible.

andreasabel avatar May 14 '23 18:05 andreasabel

maybe we can set a library-wide flag in the lib file? I think we have a few files that actually uses with-K, if flags in the file overrides the flags in the lib file, then I think we just set --cubical-compatible globally.

HuStmpHrrr avatar May 15 '23 01:05 HuStmpHrrr

we have a few files that actually uses with-K, if flags in the file overrides the flags in the lib file, then I think we just set --cubical-compatible globally.

Yes, this is exactly what I want to change in Agda, that you can override --cubical-compatible by --with-K. Currently, Agda does not allow you to do that.

andreasabel avatar May 15 '23 10:05 andreasabel

I want to do some proper benchmarking to see the effect of using --cubical-compatible. It depends on where the new code gets automatically added. If it's mostly for data, then it should be minimal. But if records change too, I'm afraid that the performance changes might be substantial.

JacquesCarette avatar May 22 '23 15:05 JacquesCarette