* [Caml-list] Unwanted type constraint in mutually recursive parameterized class type definition.
@ 2015-07-08 16:24 Philippe Veber
2015-07-08 23:57 ` Jacques Garrigue
0 siblings, 1 reply; 3+ messages in thread
From: Philippe Veber @ 2015-07-08 16:24 UTC (permalink / raw)
To: caml users
[-- Attachment #1: Type: text/plain, Size: 467 bytes --]
Dear camlers,
I obtain an unexpected answer from the toplevel when I enter the
following definition:
OCaml version 4.03.0+dev7-2015-02-08
# class type ['a] c =
object
method m : d
end
and d =
object
inherit [int] c
end
;;
class type ['a] c = object constraint 'a = int method m : d end
and d = object method m : d end
What surprises me is the constraint 'a = int in the definition of c. Is
this is a bug or feature?
Cheers,
Philippe.
[-- Attachment #2: Type: text/html, Size: 692 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Caml-list] Unwanted type constraint in mutually recursive parameterized class type definition.
2015-07-08 16:24 [Caml-list] Unwanted type constraint in mutually recursive parameterized class type definition Philippe Veber
@ 2015-07-08 23:57 ` Jacques Garrigue
2015-07-16 16:00 ` Philippe Veber
0 siblings, 1 reply; 3+ messages in thread
From: Jacques Garrigue @ 2015-07-08 23:57 UTC (permalink / raw)
To: Philippe Veber; +Cc: OCaml Mailing List
On 2015/07/09 01:24, Philippe Veber wrote:
>
> Dear camlers,
>
> I obtain an unexpected answer from the toplevel when I enter the following definition:
>
> OCaml version 4.03.0+dev7-2015-02-08
>
> # class type ['a] c =
> object
> method m : d
> end
> and d =
> object
> inherit [int] c
> end
> ;;
> class type ['a] c = object constraint 'a = int method m : d end
> and d = object method m : d end
>
> What surprises me is the constraint 'a = int in the definition of c. Is this is a bug or feature?
This is a feature (or at least, the intended behavior)
For classes, type constraints are inferred automatically, but in a monomorphic way.
A standard workaround is to open the recursion by generalizing definitions:
class type ['a,'d] c0 = object method m : 'd end
class type d = object inherit ['a,d] c0 end
class type ['a] c = ['a,d] c0
Jacques Garrigue
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Caml-list] Unwanted type constraint in mutually recursive parameterized class type definition.
2015-07-08 23:57 ` Jacques Garrigue
@ 2015-07-16 16:00 ` Philippe Veber
0 siblings, 0 replies; 3+ messages in thread
From: Philippe Veber @ 2015-07-16 16:00 UTC (permalink / raw)
To: Jacques Garrigue; +Cc: OCaml Mailing List
[-- Attachment #1: Type: text/plain, Size: 1080 bytes --]
This workaround worked just fine, thanks a lot!
ph.
2015-07-09 1:57 GMT+02:00 Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>:
> On 2015/07/09 01:24, Philippe Veber wrote:
> >
> > Dear camlers,
> >
> > I obtain an unexpected answer from the toplevel when I enter the
> following definition:
> >
> > OCaml version 4.03.0+dev7-2015-02-08
> >
> > # class type ['a] c =
> > object
> > method m : d
> > end
> > and d =
> > object
> > inherit [int] c
> > end
> > ;;
> > class type ['a] c = object constraint 'a = int method m : d end
> > and d = object method m : d end
> >
> > What surprises me is the constraint 'a = int in the definition of c. Is
> this is a bug or feature?
>
>
> This is a feature (or at least, the intended behavior)
> For classes, type constraints are inferred automatically, but in a
> monomorphic way.
> A standard workaround is to open the recursion by generalizing definitions:
>
> class type ['a,'d] c0 = object method m : 'd end
> class type d = object inherit ['a,d] c0 end
> class type ['a] c = ['a,d] c0
>
> Jacques Garrigue
[-- Attachment #2: Type: text/html, Size: 1692 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-07-16 16:01 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-08 16:24 [Caml-list] Unwanted type constraint in mutually recursive parameterized class type definition Philippe Veber
2015-07-08 23:57 ` Jacques Garrigue
2015-07-16 16:00 ` Philippe Veber
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox