From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 736767EE6B for ; Tue, 3 Dec 2013 13:58:17 +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.179; 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.179 as permitted sender) identity=mailfrom; client-ip=74.125.82.179; 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-f179.google.com) identity=helo; client-ip=74.125.82.179; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yallop@gmail.com"; x-sender="postmaster@mail-we0-f179.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQDAJTUnVJKfVKzlGdsb2JhbABahBKCerVtgRMIFg4BAQEBBwsLCRIqgiUBAQQBIx0BGx0BAwELBgULDQICJgICIgERAQUBHAYTh24BAwkGpQGMBlODCYRgChknDWSGVxEBBQyBHY1VB4JrgUgDmBSQJhgphFU8 X-IPAS-Result: AgQDAJTUnVJKfVKzlGdsb2JhbABahBKCerVtgRMIFg4BAQEBBwsLCRIqgiUBAQQBIx0BGx0BAwELBgULDQICJgICIgERAQUBHAYTh24BAwkGpQGMBlODCYRgChknDWSGVxEBBQyBHY1VB4JrgUgDmBSQJhgphFU8 X-IronPort-AV: E=Sophos;i="4.93,817,1378850400"; d="scan'208";a="39091722" Received: from mail-we0-f179.google.com ([74.125.82.179]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 03 Dec 2013 13:58:16 +0100 Received: by mail-we0-f179.google.com with SMTP id q59so13639342wes.10 for ; Tue, 03 Dec 2013 04:58:16 -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=BT5Qd1p1Z1mH3n0RFXDzKcz6o3SezAjbn8MeQstPG1k=; b=eZtX+ovTzhqBCazYuj4Ly+TeUFI8JmRtgO2zpG8aqfZnFqG+hlZJSZMpMh50akccLO L7v8vbTrL5Bo9rzAdPOYyd3FyhJ91oti9awYQOJLkGLK9ClrY3qowIxHbM4W7ZshTyNE jVnFMnQ5CkrEzU54F5QxOGDO/zFRcH2AmFLRaQJKFCovb3P3jtXgy6XJazuvwrioePgs N0kDZBCU/jPL9iBgqtJ3eAWKmrtegcM2GT/bl5FrSecxMrcTNGb8YJxn6v0gR+1MZ6T6 CERT7hKsx/0rILRx5GWcozdwdH4PTjXxH0YmeMQQvoRjNuzh49FY95iko7bShGWa5/zm YAjA== MIME-Version: 1.0 X-Received: by 10.194.236.169 with SMTP id uv9mr2163980wjc.73.1386075496637; Tue, 03 Dec 2013 04:58:16 -0800 (PST) Received: by 10.216.185.65 with HTTP; Tue, 3 Dec 2013 04:58:16 -0800 (PST) In-Reply-To: <529DCF8A.2040308@frisch.fr> References: <529BAB43.3080105@gmail.com> <529D97B4.9070108@frisch.fr> <529DCF8A.2040308@frisch.fr> Date: Tue, 3 Dec 2013 12:58:16 +0000 Message-ID: From: Jeremy Yallop To: Alain Frisch Cc: Dmitri Boulytchev , caml-list Content-Type: text/plain; charset=UTF-8 Subject: Re: [Caml-list] Confusing behaviour of type inference for polymorphic classes. On 3 December 2013 12:33, Alain Frisch wrote: > On 12/03/2013 11:17 AM, Jeremy Yallop wrote: >> 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. > > The instance on which the method is called cannot be "self", since it > corresponds to different type parameters for the class. That's true for the approach based on recursive modules, but not for the unfolding approach outlined in my earlier message, which does support recursive calls through self. > I don't know what Dmitri is exactly looking for, but maybe a polymorphic method (instead of a parametrized class) would do the job as well. Agreed. For straightforward polymorphic recursion either your recursive module approach or a simple recursive method or function is sufficient. Classes are better for open recursion, but only work either for regular types or for types with finite irregularity (i.e. where a finite number of unfoldings bring you back to the original parameter list).