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 0E35C7EF53 for ; Mon, 24 Aug 2015 08:23:03 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of christoph.hoeger@tu-berlin.de) identity=pra; client-ip=130.149.7.33; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="christoph.hoeger@tu-berlin.de"; x-sender="christoph.hoeger@tu-berlin.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of christoph.hoeger@tu-berlin.de) identity=mailfrom; client-ip=130.149.7.33; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="christoph.hoeger@tu-berlin.de"; x-sender="christoph.hoeger@tu-berlin.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail.tu-berlin.de) identity=helo; client-ip=130.149.7.33; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="christoph.hoeger@tu-berlin.de"; x-sender="postmaster@mail.tu-berlin.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AkAQCct9pVnCEHlYJdDoNhaYMlvDaGAwKBJUwBAQEBAQESAQEBAQEICwkJIS6EJAEBAwEjVQEFCwshFgsCAgIHAwIBAgFFBg0GAgEBF4gLCASwYJUvAQEBAQEBBAEBAQEBHYtXhG8bB4JpgUMFlTSCQIFcaol9hmCRX4NmQG+CTAEBAQ X-IPAS-Result: A0AkAQCct9pVnCEHlYJdDoNhaYMlvDaGAwKBJUwBAQEBAQESAQEBAQEICwkJIS6EJAEBAwEjVQEFCwshFgsCAgIHAwIBAgFFBg0GAgEBF4gLCASwYJUvAQEBAQEBBAEBAQEBHYtXhG8bB4JpgUMFlTSCQIFcaol9hmCRX4NmQG+CTAEBAQ X-IronPort-AV: E=Sophos;i="5.15,736,1432591200"; d="zsh'?scan'208";a="143596488" Received: from mail.tu-berlin.de ([130.149.7.33]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Aug 2015 08:23:02 +0200 X-tubIT-Incoming-IP: 91.64.68.238 Received: from ip5b4044ee.dynamic.kabel-deutschland.de ([91.64.68.238] helo=[192.168.178.42]) by mail.tu-berlin.de (exim-4.76/mailfrontend-5) with esmtpsa [UNKNOWN:AES128-SHA:128] id 1ZTl9o-0005Um-6y; Mon, 24 Aug 2015 08:23:01 +0200 References: <55D827DB.3010506@tu-berlin.de> <55D85FE7.2050001@tu-berlin.de> <0D467B24-3C94-4640-8264-85BE5312EB55@math.nagoya-u.ac.jp> Cc: caml-list@inria.fr To: Jacques Garrigue From: =?UTF-8?Q?Christoph_H=c3=b6ger?= Organization: =?UTF-8?Q?Technische_Universit=c3=a4t_Berlin?= Message-ID: <55DAB843.5010800@tu-berlin.de> Date: Mon, 24 Aug 2015 08:22:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <0D467B24-3C94-4640-8264-85BE5312EB55@math.nagoya-u.ac.jp> Content-Type: multipart/mixed; boundary="------------000204090901050608050209" X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.8.24.61516 X-PMX-Spam: Gauge=IIIIIII, Probability=0%, Report='' Subject: Re: [Caml-list] Expansion of type-constructors in ctype.ml This is a multi-part message in MIME format. --------------000204090901050608050209 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Am 24.08.2015 um 00:18 schrieb Jacques Garrigue: > This is indeed a pretty difficult problem, as you must be careful of not > changing the semantics of unification. > Until recently, the only solution was to expand the type, as there was > no static information cacheing whether an argument was used in the > body or not. > However, since relatively recent changes about variance information > (the switch to 7 flags…), we actually have at least an approximation > of which unifications must be done imperatively, and which needn’t > be done at all. > So it might be doable at least for part of the parameters. That sounds interesting. What are the relevant variance flags? > I would have to see the code to tell you more. > As stated above, the real problem is the length of the cycles in the expanded > graph. I really do not think that this is related to any cycles. It is just about large unfolded types. I attached a script to generate a meaningful example. When I try to run ocamlbuild m_9.cmo, it takes ~30s already. A preliminary patched version of the ocaml compiler can handle this particular example in pretty much no time at all. regards, Christoph -- Christoph Höger Technische Universität Berlin Fakultät IV - Elektrotechnik und Informatik Übersetzerbau und Programmiersprachen Sekr. TEL12-2, Ernst-Reuter-Platz 7, 10587 Berlin Tel.: +49 (30) 314-24890 E-Mail: christoph.hoeger@tu-berlin.de --------------000204090901050608050209 Content-Type: text/plain; charset=UTF-8; name="create.zsh" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="create.zsh" IyEvdXNyL2Jpbi9lbnYgenNoCgpmb3IgKChpID0gMSA7IGkgPCAxMCA7IGkr KykpIDsgZG8KICBlY2hvICJjbGFzcyBbJ2FdIGMgKGEgOiAnYSkgPSBvYmpl Y3QiID4gbV8kaS5tbAogIGVjaG8gIiAgbWV0aG9kIG1fMSA9IChuZXcgTV8k KChpLTEpKS5jKSBhI2ZvbyIgPj4gbV8kaS5tbAogIGVjaG8gIiAgbWV0aG9k IG1fMiA9IChuZXcgTV8kKChpLTEpKS5jKSBhI2ZvbyIgPj4gbV8kaS5tbAog IGVjaG8gIiAgbWV0aG9kIG1fMyA9IChuZXcgTV8kKChpLTEpKS5jKSBhI2Zv byIgPj4gbV8kaS5tbAogIGVjaG8gIiAgbWV0aG9kIG1fNCA9IChuZXcgTV8k KChpLTEpKS5jKSBhI2ZvbyIgPj4gbV8kaS5tbAogIGVjaG8gImVuZCIgPj4g bV8kaS5tbApkb25lCgplY2hvICJjbGFzcyBbJ2FdIGMgKGEgOiAnYSkgPSBv YmplY3QgbWV0aG9kIG1fMSA9IGEjZm9vIG1ldGhvZCBtXzIgPSBhI2ZvbyBl bmQiID4gbV8wLm1s --------------000204090901050608050209--