Mantis Bug Tracker
Main | My View | View Issues | Change Log | Roadmap
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007152OCamltypingpublic2016-02-19 12:582017-09-24 17:33
Reporterbobot 
Assigned Togarrigue 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Version4.03.0+dev / +beta1Fixed in Version4.03.0+dev / +beta1 
Summary0007152: A typing equality is lost in 4.03 branch compared to 4.02.3
DescriptionThe file variable.ml compile with 4.02.3 but not with 4.02.3.

```
ocamlc -o /tmp/dumb -c variable.ml
File "variable.ml", line 5, characters 6-667:
Error: Signature mismatch:
       ...
       Values do not match:
         val add_dec : dec:Data.t -> unit
       is not included in
         val add_dec : dec:make_dec -> unit
       File "src/variable.ml", line 3, characters 2-35: Expected declaration
       File "src/variable.ml", line 63, characters 4-11: Actual declaration
```

I'm not able to minimize it more (except in fact the label can be removed...).
TagsNo tags attached.
Attached Files? file icon variable.ml [^] (735 bytes) 2016-02-19 12:58 [Show Content]

- Relationships
related to 0006752resolvedgarrigue Extensible variant types and scope escaping 
related to 0007313assignedgarrigue Typing regression between 4.03 and 4.04 branch with signature coercion. 

-  Notes
(0015375)
bobot (reporter)
2016-02-19 13:00

 Of course it should be read `The file variable.ml compile with 4.02.3 but not with 4.03 branch.`
(0015376)
bobot (reporter)
2016-02-19 13:13

 The fact that `Data.t` is not known as `Dem.Data.t` might be the culprit.
(0015440)
garrigue (manager)
2016-03-06 08:06

 That's indeed bad, For some reason, the first component of the path is dropped.
Have to fix it before the release.

Here is a simpler version.

type 'a t

module type S = sig
  module Data: sig type t end
  val key: Data.t t
end
module Register (D:S) = struct end
module M = struct
  module Data = struct type t = int end
  let key : _ t = Obj.magic ()
end
module EM = Register(M);;

Which gives the meaningless answer:

# M.key;;
- : Data.t t = <abstr>
(0015441)
garrigue (manager)
2016-03-06 15:22

 Fix in 4.03 and trunk by commits 05922fa and 35f10d6.

I'm not 100% clear of why it worked before, because non-generalized variables inside submodules have always been strange.
I think this fix does the right thing, as it lowers their levels when one adds a module to the environment, putting them at most at the binding level of this module, so that all references inside this module will be expanded to an external path.
(0016194)
garrigue (manager)
2016-08-08 11:30

 Copied from MPR#7313:

It took me a while, but here is what this PR is about.
This is related to the following type:

module Dem : sig
  module Data : sig type t = make_dec end
  val key : '_a Fast.t
end

You should instantiate '_a by either Data.t or Dem.Data.t, depending on whether you are looking at the type from inside Dem or outside Dem. Since the variable is shared between the two, actually both are invalid. So the solution to 7152 solved this by forcing the expansion, and instantiating by make_dec, which is correct. But this also means that you cannot instantiate such a non-generalizable type variable by an internal abstract type (except when you are coercing before adding the module definition to the environment, since the locking is only done afterward).

I understand that all this kind of worked until 4.02.3, but my feeling is that this was purely by chance. Something like lazyness allowing one to instantiate with an internal reference before the exporting substitution occurs, so that the internal-external conflict is avoided.

The cause this started to fail is probably a change in evaluation order somewhere, but I'm not sure it's worth tracking it down, because it is bound to be fragile.

Just to give you an idea of how the original approach was fragile, it was sufficient to add the line

  let _ = Dem.key

just after the definition of Dem above to break it in all versions up to 4.02.
It worked in 4.03, but only by making things more laxist, and there were other problems.

The more restrictive approch implemented here fixes it once and for all, but introduces some regressions, as seen in MPR#7313.

- Issue History
Date Modified Username Field Change
2016-02-19 12:58 bobot New Issue
2016-02-19 12:58 bobot File Added: variable.ml
2016-02-19 13:00 bobot Note Added: 0015375
2016-02-19 13:13 bobot Note Added: 0015376
2016-02-25 15:52 doligez Status new => acknowledged
2016-02-25 15:52 doligez Target Version => 4.03.0+dev / +beta1
2016-03-06 08:06 garrigue Note Added: 0015440
2016-03-06 08:06 garrigue Assigned To => garrigue
2016-03-06 08:06 garrigue Status acknowledged => confirmed
2016-03-06 15:22 garrigue Note Added: 0015441
2016-03-06 15:22 garrigue Status confirmed => resolved
2016-03-06 15:22 garrigue Fixed in Version => 4.03.0+dev / +beta1
2016-03-06 15:22 garrigue Resolution open => fixed
2016-06-23 01:30 garrigue Relationship added related to 0006752
2016-08-08 10:56 garrigue Relationship added related to 0007313
2016-08-08 11:30 garrigue Note Added: 0016194
2017-02-23 16:45 doligez Category OCaml typing => typing
2017-09-24 17:33 xleroy Status resolved => closed

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker