From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <yallop@gmail.com>
X-Original-To: caml-list@sympa.inria.fr
Delivered-To: caml-list@sympa.inria.fr
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104])
	by sympa.inria.fr (Postfix) with ESMTPS id 225067EE6B
	for <caml-list@sympa.inria.fr>; Tue,  3 Dec 2013 11:17:02 +0100 (CET)
Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender
  authenticity information available from domain of
  yallop@gmail.com) identity=pra; client-ip=74.125.82.182;
  receiver=mail3-smtp-sop.national.inria.fr;
  envelope-from="yallop@gmail.com";
  x-sender="yallop@gmail.com"; x-conformance=sidf_compatible
Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of
  yallop@gmail.com designates 74.125.82.182 as permitted
  sender) identity=mailfrom; client-ip=74.125.82.182;
  receiver=mail3-smtp-sop.national.inria.fr;
  envelope-from="yallop@gmail.com";
  x-sender="yallop@gmail.com"; x-conformance=sidf_compatible;
  x-record-type="v=spf1"
Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender
  authenticity information available from domain of
  postmaster@mail-we0-f182.google.com) identity=helo;
  client-ip=74.125.82.182;
  receiver=mail3-smtp-sop.national.inria.fr;
  envelope-from="yallop@gmail.com";
  x-sender="postmaster@mail-we0-f182.google.com";
  x-conformance=sidf_compatible
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQDAPeunVJKfVK2lGdsb2JhbABahBKCerVtgRIIFg4BAQEBBwsLCRIqgiUBAQUjHQEbHQEDDAYFCw0CAiYCAiIBEQEFARwGEwgSAYdTAQMPpFqMBlODCYRTChknDWSGVxEBBQyBHY1VB4JrgUgDmBSQJhgphFU8
X-IPAS-Result: AgQDAPeunVJKfVK2lGdsb2JhbABahBKCerVtgRIIFg4BAQEBBwsLCRIqgiUBAQUjHQEbHQEDDAYFCw0CAiYCAiIBEQEFARwGEwgSAYdTAQMPpFqMBlODCYRTChknDWSGVxEBBQyBHY1VB4JrgUgDmBSQJhgphFU8
X-IronPort-AV: E=Sophos;i="4.93,817,1378850400"; 
   d="scan'208";a="39066844"
Received: from mail-we0-f182.google.com ([74.125.82.182])
  by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 03 Dec 2013 11:17:01 +0100
Received: by mail-we0-f182.google.com with SMTP id q59so13155757wes.41
        for <caml-list@inria.fr>; Tue, 03 Dec 2013 02:17:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        bh=TfWwTztfOaPX0so4I5epYMVnvVnLvLUGOHwwjZF06ps=;
        b=tyxn39+pp5BnUo40PqiXWGK2PizGYDCirXltxHahXIHAY/Em3GJcJAc2LozdtAKMq/
         VKFmkZJuqFFKcHCMn80TRJ6JnPgr85oLzMDReAlt77IZeq6F0hRJheOkGYE2IlfjTOOs
         pZsSACgREv3FYlYQrYBLclEDNDcdFOZOAV83p3t9O08iuEsLFtXSqEPkBXFMBfSIacGk
         4RhSQhqAffZeNwZ7R+3/eVue9VxlCZtb6h76J+i49LzolkRWfUnr1s8cTt5s+/ALh7+m
         GW6b8jxj8QPtK/RMkT12THVm1dlPMMmpvMCDdsZvtyD+i1GyURlvKJbVqM71u9zGDo9g
         WwaA==
MIME-Version: 1.0
X-Received: by 10.194.122.131 with SMTP id ls3mr33291439wjb.0.1386065820814;
 Tue, 03 Dec 2013 02:17:00 -0800 (PST)
Received: by 10.216.185.65 with HTTP; Tue, 3 Dec 2013 02:17:00 -0800 (PST)
In-Reply-To: <529D97B4.9070108@frisch.fr>
References: <529BAB43.3080105@gmail.com>
	<CAAxsn=Fs2s_fUuFM4tqq+EbdVo-Ofr_0X0ZezJLaXdg5GcEn_Q@mail.gmail.com>
	<529D97B4.9070108@frisch.fr>
Date: Tue, 3 Dec 2013 10:17:00 +0000
Message-ID: <CAAxsn=H94K0Cshn4qg1iFpnknSm4Bi1hk1UiCwcU5mEjCJt2_A@mail.gmail.com>
From: Jeremy Yallop <yallop@gmail.com>
To: Alain Frisch <alain@frisch.fr>
Cc: Dmitri Boulytchev <dboulytchev@gmail.com>, caml-list <caml-list@inria.fr>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [Caml-list] Confusing behaviour of type inference for
 polymorphic classes.

On 3 December 2013 08:35, Alain Frisch <alain@frisch.fr> wrote:
> On 12/02/2013 04:24 PM, Jeremy Yallop wrote:
>> There's good news and bad news.  The good news is that the problem can
>> be solved for your particular example.  The bad news is that the
>> approach doesn't work in the general case.
>
> A more general solution is based on recursive modules:

Using recursive modules certainly makes it possible to write a class
with the correct type, but unless I'm mistaken you lose the ability to
override the behaviour on recursive calls -- i.e. the call to (new
X.m)#t can no longer be replaced with a call through a self variable.