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 D27057EE99 for ; Mon, 9 Dec 2013 14:48:13 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of dboulytchev@gmail.com) identity=pra; client-ip=209.85.215.41; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dboulytchev@gmail.com"; x-sender="dboulytchev@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of dboulytchev@gmail.com designates 209.85.215.41 as permitted sender) identity=mailfrom; client-ip=209.85.215.41; receiver=mail3-smtp-sop.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 (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-la0-f41.google.com) identity=helo; client-ip=209.85.215.41; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dboulytchev@gmail.com"; x-sender="postmaster@mail-la0-f41.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncGAOzIpVLRVdcplWdsb2JhbABZhxG2EgICgS8WDgEBAQEHDQkJEiqCJQEBBAEjBBEIARscAQEDAQsGBQsPAgUWCwICCQMCAQIBEREBBQEcBg0BBwEBh2sBAwkGBAGlbowGU4MJhBIKGScNZIYDEQEFDIEdjU4ZB4JrgUgDiTyJWYEcg2OGRYlhQYRa X-IPAS-Result: AncGAOzIpVLRVdcplWdsb2JhbABZhxG2EgICgS8WDgEBAQEHDQkJEiqCJQEBBAEjBBEIARscAQEDAQsGBQsPAgUWCwICCQMCAQIBEREBBQEcBg0BBwEBh2sBAwkGBAGlbowGU4MJhBIKGScNZIYDEQEFDIEdjU4ZB4JrgUgDiTyJWYEcg2OGRYlhQYRa X-IronPort-AV: E=Sophos;i="4.93,858,1378850400"; d="scan'208";a="40060719" Received: from mail-la0-f41.google.com ([209.85.215.41]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 09 Dec 2013 14:48:13 +0100 Received: by mail-la0-f41.google.com with SMTP id eo20so1621002lab.28 for ; Mon, 09 Dec 2013 05:48:10 -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=8sG2qcwWrq6B9FliIbT7+fPExkV2AiJttQj7sLe7kJM=; b=doJQ+uzdzSyEtp8m3QBLoJO8fMi+Hawgm/oWQhzOlJRjYriJmxSWYFwcVbg/bcYhkW C+VQf2FiWXmGb0qJyqT3AI8Kam3vsVy6CIVQdCvSJtTTFw+dNny3+OVmKSeGU1dWCZAI Hvj7OJTVSxofei+A9l2FZkbtlwFFqqnfxOeo6jajknSiRWBOzOspnnOqzoeWjsW9oKD4 gwhNqaUFSX3afNSqyKaG8ImIaKZwgwjviXotVlnsvmAgJHcnBukTJ3y6x+UcoZGJXPFD V+EQo2sFNOQQ9BfbZOZ1yjSecy4gp6MuQD5hpSUhndoI0ySmpwTG38fB1s4pmD0bVoNc Y56A== X-Received: by 10.152.120.231 with SMTP id lf7mr5308170lab.36.1386596890314; Mon, 09 Dec 2013 05:48:10 -0800 (PST) Received: from [172.20.208.125] ([80.76.244.114]) by mx.google.com with ESMTPSA id r10sm14650272lag.7.2013.12.09.05.48.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 05:48:09 -0800 (PST) Message-ID: <52A5CA18.1070408@gmail.com> Date: Mon, 09 Dec 2013 17:48:08 +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 CC: caml-list References: <529BAB43.3080105@gmail.com> <529D97B4.9070108@frisch.fr> <529DCF8A.2040308@frisch.fr> <529E198F.7060704@gmail.com> 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. > Yes, it's a neat approach! One small suggestion: in order to handle > the case where the type you're traversing has multiple recursive > instantations with different parameters you might consider passing the > instance creation function in a way that allows it to be called > polymorphically (e.g. by wrapping it in a record with a polymorphic > field): Of course; this is yet another workaround to make it possible to use that workaround :) > There is one last thing I'm curious about. The difficulties that > you're avoiding with open recursion seem to arise from the > representation of the traversal as a parameterised class with a > monomorphic method. The reason is quite simple --- class parameters are used to represent the *result* type of the transformation, not the parameters of the transforming type. I simplified the example just to clarify the polymorphic class issues. In reality what I'm interested in is somewhat like this: for a type ('a, 'b, ...) t = A ... | B ... | C ... we generate a virtual class class virtual ['ta, 'tb, ..., 'inh, 'syn] t_t = object method virtual c_A : method virtual c_B : etc. end which represents some attribute transformation with inherited attribute type 'inh; the type of synthesized attribute for type 'a is 'ta, for 'b is 'tb etc., for type ('a, 'b, ...) t is 'syn. The methods of the class handle the individual constructors; the arguments for these methods capture the transformation function as well. For example, for regular map we have the following bindings: class ['ta, 'tb, ...] map_t = object inherit ['ta, 'tb, ..., unit, ('ta, 'tb, ...) t] t_t ... end for show we have class show_t = object inherit [string, string, ..., unit, string] t_t ... end for, say, eval class eval_t = object inherit [int, int, ..., string -> int, int] t_t ... end etc. Under this representation we might need the single shallow-traversal generic function to implement all these transformations. Per-constructor object encoding allows modification with less boilerplate code (via inhertance); in addition if we have a polymorphic-variant type t = [ a | b | c ... ] then the certain transformation for t can be constructed by regular class inheritance from the implementations of the same transformation for it's counterparts. Best regards, Dmitry. P.S. I was'nt offended by your long message (but surprised a little bit ).