|Anonymous | Login | Signup for a new account||2013-12-12 01:27 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006147||OCaml||OCaml typing||public||2013-08-29 13:30||2013-09-03 01:32|
|Target Version||4.01.1+dev||Fixed in Version|
|Summary||0006147: Typing error with almost the same signature|
|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 [^]|
|Tags||No tags attached.|
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.
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.
Ok, thanks. As for me, this is fixed (see here: https://github.com/ocsigen/ocsimore/commit/663e47febd2964b0e3494053ea1fd4854ef064c0 [^])
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 :
(([> Html5_types.input ] as 'b)
'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) ->
'a option ->
([> Html5_types.input ] Eliom_content.Html5.F.elt, 'b option) t
File "src/core/server/xform.ml", line 583, characters 6-15:
Setting target to "after-next" as this is not blocking for the 4.01.0 release. If you disagree, react quickly.
|It's ok. It's not really a bug and it's fixed for me, so, yes it's not blocking.|
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.
|2013-08-29 13:30||jpdeplaix||New Issue|
|2013-08-30 01:30||garrigue||Assigned To||=> garrigue|
|2013-08-30 01:30||garrigue||Status||new => assigned|
|2013-08-30 01:36||garrigue||Note Added: 0010258|
|2013-08-30 01:36||garrigue||Status||assigned => feedback|
|2013-08-30 13:54||lefessan||Note Added: 0010262|
|2013-08-30 22:29||jpdeplaix||Note Added: 0010274|
|2013-08-30 22:29||jpdeplaix||Status||feedback => assigned|
|2013-09-02 11:14||doligez||Note Added: 0010293|
|2013-09-02 11:14||doligez||Target Version||=> 4.01.1+dev|
|2013-09-02 15:42||jpdeplaix||Note Added: 0010297|
|2013-09-03 01:32||garrigue||Note Added: 0010298|
|Copyright © 2000 - 2011 MantisBT Group|