Hello.
> I know of the "double vision" problem, and I am actually confused by
> the post which you reference. I think it discusses an old version of
> the typechecker, as the example which Xavier Leroy gives supposedly to
> illustrate the flaw now (3.10.2) properly type-checks:
Yes; I was forgett
Hello,
Thank you for your attempts ...
I know of the "double vision" problem, and I am actually confused by
the post which you reference. I think it discusses an old version of
the typechecker, as the example which Xavier Leroy gives supposedly to
illustrate the flaw now (3.10.2) properly type-ch
Hello.
I could not solve your problem, but I report my attempt encountering
a known limitation of the type checker, which may be of some help to you.
The following program raises a type error:
"This expression has type Boxes.T.t but is here used with type B.t"
when typing the second branch of A.o
Hello,
> Can I look at the code which does not type check without Obj.magic?
> Ideally something like if I comment out Obj.magic then I get a type
> error, and if I comment it in then the code type checks, so that I can
> identify the point of the issue? (In the context of this simplified
> exampl
Hello,
> I have been unable to cleanly specify the code below (or something
> equivalent) without resorting to Obj.magic. (In the example below,
> "Boxes.B.t" as referenced by the Validator module would ideally simply
> be "Boxes.t", and Validator would not "see" the submodules;)
Can I look at t
Hello,
In the same vein as:
let rec p_even odd x =
if x = 1 then false
else x = 0 || (odd (x - 1))
let rec p_odd even x =
if x = 0 then false
else x = 1 || (even (x - 1))
...
let rec even x = p_even odd x
and odd x = p_odd even x
where I define two mutually rec
