Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Universes #17

Open
Zimmi48 opened this issue Mar 25, 2019 · 10 comments
Open

Universes #17

Zimmi48 opened this issue Mar 25, 2019 · 10 comments

Comments

@Zimmi48
Copy link
Contributor

Zimmi48 commented Mar 25, 2019

This discussion is bound to happen at some point, so we might just as well start a new thread now, with this quote from @HuStmpHrrr on Coq-Club:

I am not sure if stdlib2 plans to make things primarily in Type and make use of sProp whenever necessary. If that's the case, it would make the future much brighter.

I'm not really expecting any answer now, just recording this for later.

@HuStmpHrrr
Copy link

thank you for opening this issue.

It seems stdlib2 is getting started and there are some Prop's around already. I think this is a very important design decision and is probably not straightforward to revert. not sure how should this be organized.

@SkySkimmer
Copy link
Contributor

I'm not clear on what the issue with using Prop is.

@HuStmpHrrr
Copy link

HuStmpHrrr commented Mar 25, 2019

the issue with Prop is if a property relies on elimination on another definition, and if that definition is Prop, it will pretty much force all related definitions to be Prop too.

I find Prop is so hard to use and very unnecessary. for example, Exists for lists is so strange to be defined in Prop: https://coq.inria.fr/library/Coq.Lists.List.html#Exists

the situation here, is Exists is so weak that I don't even know which index the target proposition is witnessed, despite the fact that all lists are finite. why I wouldn't want to know about the index provided the information has already been here? figuring out which index is the witness pretty much requires power to decide all propositions, and therefore LEM or Choice.

I think there can be more examples. I hope I am not too shallow but I am fairly scared of Prop now. defining in Prop is really a design decision that "there will not be any users in the future who need to inspect the internal language", but how can that be true in general? all the questions I posted the other days on coq-club can all be resolved in trivial ways, if all my dependencies were not operating in Prop.

after all, there are so many problems that can be defined in proof relevant way, so why they need to be made irrelevant with no obvious advantage? I find it very strange.

@spitters
Copy link

spitters commented Mar 25, 2019 via email

@gmalecha
Copy link

gmalecha commented Sep 9, 2020

Are types exposed by stdlib2 universe polymorphic? I didn't notice any Set Universe Polymorphism, but I did see Global Unset Auto Template Polymorphism. Does that make everything universe polymorphic?

@gmalecha
Copy link

@spitters Prop has the "benefit" of being impredicative. That might factor into things as well.

@Zimmi48
Copy link
Contributor Author

Zimmi48 commented Sep 10, 2020

I didn't notice any Set Universe Polymorphism, but I did see Global Unset Auto Template Polymorphism. Does that make everything universe polymorphic?

It doesn't but I would expect this to be the objective (or at least some attempt to be made).

@spitters
Copy link

@gmalecha I wonder who is using Prop without wanting to use UIP too.

@ppedrot
Copy link
Contributor

ppedrot commented Sep 11, 2020

@spitters do you mean proof-irrelevance rather than UIP? In that case there are some use-cases for impredicative set (which is still part of the kernel of Coq AFAIK) geared towards programming. At some point we relied on this to extract the tactic monad, an actually case of bootstrapping. Stuff like Mendler's encoding is another example from the top of my head.

@spitters
Copy link

@ppedrot Yes, I meant PI.
Indeed, I use impredicative set in some of my programming exercises for Fw, but I wouldn't put it in stdlib2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants