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

Typing error with almost the same signature #6147

Closed
vicuna opened this issue Aug 29, 2013 · 7 comments
Closed

Typing error with almost the same signature #6147

vicuna opened this issue Aug 29, 2013 · 7 comments
Assignees
Milestone

Comments

@vicuna
Copy link

vicuna commented Aug 29, 2013

Original bug ID: 6147
Reporter: jpdeplaix
Assigned to: @garrigue
Status: closed (set by @garrigue on 2014-04-04T05:24:15Z)
Resolution: not a bug
Priority: normal
Severity: major
Version: 4.01.0+beta/+rc
Target version: 4.01.1+dev
Category: typing

Bug description

Ocsimore (an eliom web site) is unable to compile with ocaml 4.01. It fails with a strange error message (see the following link). I tried to change the signature, but the wanted signature changed too and I abandoned.
So, sorry if I don't help that much, but at least I made a report.
Maybe someone can take a look at this.

Steps to reproduce

https://ci.inria.fr/ocsigen/view/4.01/job/Ocsimore-4.01/lastFailedBuild/console

@vicuna
Copy link
Author

vicuna commented Aug 29, 2013

Comment author: @garrigue

The error message is not strange:
it tells you that in the internal type, the type parameter of
Eliom_content_core.Html5.elt is shared between the input argument
and the result type, while in the signature it is not.
If both t and Eliom_content_core.Html5.elt are covariant in their
parameter, this can be solved by adding an explicit coercion
(... : (Html5_types.input Eliom_content.Html5.F.elt, _) t
:> ([> Html5_types.input ] Eliom_content.Html5.F.elt, _) t)
in the implementation file.

I do not know exactly while this input-output relation was not enforced
in ocaml 4.00. Note that some soundness bugs were fixed in 4.01.

@vicuna
Copy link
Author

vicuna commented Aug 30, 2013

Comment author: @lefessan

I got a similar message once with trunk, it was caused by type annotations in the code. 4.01 propagates such type annotations, instead of just verifying that they are correct.

I found that, by removing the type annotation (that was useless), the problem would go away.

@vicuna
Copy link
Author

vicuna commented Aug 30, 2013

Comment author: jpdeplaix

Ok, thanks. As for me, this is fixed (see here: ocsigen/ocsimore@663e47f)

Note: I'm coping here the error, because the link may not be available later (for those who wants to see it):

File "src/core/server/xform.ml", line 1:
Error: The implementation src/core/server/xform.ml
does not match the interface src/core/server/xform.cmi:
...
In module Xform:
Values do not match:
val opt_input :
input:('a ->
(([> Html5_types.input ] as 'b)
Eliom_content_core.Html5.elt, 'c)
t) ->
default:'a ->
'a option -> ('b Eliom_content_core.Html5.elt, 'c option) t
is not included in
val opt_input :
input:('a -> (Html5_types.input Eliom_content.Html5.F.elt, 'b) t) ->
default:'a ->
'a option ->
([> Html5_types.input ] Eliom_content.Html5.F.elt, 'b option) t
File "src/core/server/xform.ml", line 583, characters 6-15:
Actual declaration

@vicuna
Copy link
Author

vicuna commented Sep 2, 2013

Comment author: @damiendoligez

Setting target to "after-next" as this is not blocking for the 4.01.0 release. If you disagree, react quickly.

@vicuna
Copy link
Author

vicuna commented Sep 2, 2013

Comment author: jpdeplaix

It's ok. It's not really a bug and it's fixed for me, so, yes it's not blocking.

@vicuna
Copy link
Author

vicuna commented Sep 2, 2013

Comment author: @garrigue

Fabrice, your comment disturbs me.
The propagation is only intended to type more programs, not less.
If this is the opposite, there is a bug somewhere.
Does anybody have an analyzable repro case?

On the other hand, as I wrote in my previous comment, independently of the improved propagation, 4.01 is actually stricter (i.e. less polymorphic) than 4.00 for some constructs. It tries to stay closer to the specification. So this is certainly a plausible cause.

@vicuna
Copy link
Author

vicuna commented Apr 4, 2014

Comment author: @garrigue

Close this one, as the problem seems solved.

@vicuna vicuna closed this as completed Apr 4, 2014
@vicuna vicuna added the typing label Mar 14, 2019
@vicuna vicuna added this to the 4.01.1 milestone Mar 14, 2019
@vicuna vicuna added the bug label Mar 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants