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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 711ED7EE6B for ; Tue, 3 Dec 2013 18:49:07 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of dboulytchev@gmail.com) identity=pra; client-ip=209.85.215.49; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="dboulytchev@gmail.com"; x-sender="dboulytchev@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of dboulytchev@gmail.com designates 209.85.215.49 as permitted sender) identity=mailfrom; client-ip=209.85.215.49; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="dboulytchev@gmail.com"; x-sender="dboulytchev@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-la0-f49.google.com) identity=helo; client-ip=209.85.215.49; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="dboulytchev@gmail.com"; x-sender="postmaster@mail-la0-f49.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAGAGAZnlLRVdcxlGdsb2JhbABahwy1aQICgRsWDgEBAQEHCwsJEiqCJQEBBAEjBBEIARscAQEDDAYFCw8CBRYLAgIJAwIBAgEREQEFARwGAQwBBwEBF4dTAQMJBgQBpSWMBlODCYRAChknDWSGQxEBBQyBHY0iMweCa4FIA4k8jliGRYlhQYRa X-IPAS-Result: AjAGAGAZnlLRVdcxlGdsb2JhbABahwy1aQICgRsWDgEBAQEHCwsJEiqCJQEBBAEjBBEIARscAQEDDAYFCw8CBRYLAgIJAwIBAgEREQEFARwGAQwBBwEBF4dTAQMJBgQBpSWMBlODCYRAChknDWSGQxEBBQyBHY0iMweCa4FIA4k8jliGRYlhQYRa X-IronPort-AV: E=Sophos;i="4.93,819,1378850400"; d="scan'208";a="46776833" Received: from mail-la0-f49.google.com ([209.85.215.49]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 03 Dec 2013 18:49:06 +0100 Received: by mail-la0-f49.google.com with SMTP id er20so9123787lab.8 for ; Tue, 03 Dec 2013 09:49:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=eetnM3SON1ZvqtvyHFGT7p8BdxgiEV9s0FM9d4QVtr4=; b=QpzXyshF9vuPcucpn3+I0eqsOzYtE80LdD3+T0Jey0elBEqtxNPskpE2lWiW/GyUNC lnrZdehJJ5TYyzksIA9kZmFyPIJeUXD7Sur8vP6B8Emp/iU8nuT87QCnhz+4tILmqz8e 9vdahBKhuLdnN4UATZu9GOekOGlMkSrXNbadIu4oTUuxk2Jv7nKqC1tIIDnNMg2V+SSw 4dMLxKZyljBRXkI0/xrirWBXp9IZJSKTI4ntWAfXLAq8JU7VkrweycUQBqOGNRn7DVWr t5Mc7WP79b4rQ5YQDUFkPtY60RXwUhNnFTmDL2IwrFQL6pUU2Ab/r51mEKW8F8z0v6IT p1dg== X-Received: by 10.152.19.65 with SMTP id c1mr2248825lae.49.1386092945733; Tue, 03 Dec 2013 09:49:05 -0800 (PST) Received: from [172.20.208.125] (lagarm-2.ip.PeterStar.net. [81.3.129.2]) by mx.google.com with ESMTPSA id sd11sm86455258lab.2.2013.12.03.09.49.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 09:49:04 -0800 (PST) Message-ID: <529E198F.7060704@gmail.com> Date: Tue, 03 Dec 2013 21:49:03 +0400 From: Dmitri Boulytchev User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Jeremy Yallop , Alain Frisch CC: caml-list References: <529BAB43.3080105@gmail.com> <529D97B4.9070108@frisch.fr> <529DCF8A.2040308@frisch.fr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] Confusing behaviour of type inference for polymorphic classes. Jeremy, Alain, the code snippet I presented was actually boiled down from the more complex example. I don't have any particular interest to the concrete type t; I'm ok to give up on "finitely regularizable" types but I definitely don't want to give up on GADTs which might be essentially irregular. > As you've noted, you can work around the > problem using open recursion and typing the knot yourself, but you > lose the ability to subtype in the process. Well, having the solution with the polymorphic recursive function class ['a, 'b, 'ta, 'tb] proto_m f = object ... end let rec f : 'a 'b 'ta 'tb . unit -> ('a, 'b, 'ta, 'tb) #proto_m = fun () -> new proto_m f class ['a, 'b, 'ta, 'tb] m = ['a, 'b, 'ta, 'tb] proto_m f it is possible to inherit from proto_m: class ['a, 'b, 'ta, 'tb] m' f = object inherit ['a, 'b, 'ta, 'tb] proto_m f as super method t fa fb s = match s with | A (a, bat) -> ; super#t fa fb s | B a -> ; super#t fa fb s end let rec g : 'a 'b 'ta 'tb . unit -> ('a, 'b, 'ta, 'tb) #proto_m = fun () -> new m' g class ['a, 'b, 'ta, 'tb] subm = ['a, 'b, 'ta, 'tb] m' g Here subm is a legitimate subclass of m with the desired behaviour (this property can not be achieved with the recursive module though it is really much more elegant way to provide the proper instantiation for class type parameters). So I don't see why I'm loosing the ability to subtype. It seems to me that this workaround can be used to overcome the "regular class" restriction completely in a syntax-conversion manner. I appreciate any comments. Dmitry.