Skip to Content.
Sympa Menu

coq-club - Re: [Coq-Club] API: How to generate a sort type for the parameter of an abstraction

coq-club AT inria.fr

Subject: The Coq mailing list

List archive

Re: [Coq-Club] API: How to generate a sort type for the parameter of an abstraction


Chronological Thread 
  • From: Sylvain Boulmé <Sylvain.Boulme AT imag.fr>
  • To: coq-club AT inria.fr
  • Subject: Re: [Coq-Club] API: How to generate a sort type for the parameter of an abstraction
  • Date: Thu, 6 Oct 2016 11:33:05 +0200
  • Authentication-results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=Sylvain.Boulme AT imag.fr; spf=Pass smtp.mailfrom=Sylvain.Boulme AT imag.fr; spf=None smtp.helo=postmaster AT mx1.imag.fr
  • Mailscanner-null-check: 1476351186.8052@GrV5ghD0djOnCPsGMf5djQ

Thanks a lot Guillaume,

Le 06/10/2016 à 09:22, Guillaume Melquiond a écrit :

As far as I know, you are supposed to call Typing.type_of on your newly
created term. That will return a new evarmap that should pass to
tclEVARS rather than the old one (which does not contain enough universe
constraints for checking that your new term is well-typed).

Yes, applying this solve my issue.

Unfortunately, it means type-checking your term twice, which you
precisely wanted to avoid since you are calling exact_no_check. Another
solution is thus not too call Typing.type_of on your new term, but on a
smaller simpler dummy term. If your dummy term (whatever its type)
happens to produce the exact same universe constraints as your new term,
then you are good to go and you can use the produced evarmap instead.


This very smart trick seems also to work very well ;-)

Thanks again !

Sylvain.





Archive powered by MHonArc 2.6.18.

Top of Page