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 B053B7F0D9 for ; Tue, 25 Aug 2015 17:47:57 +0200 (CEST) IronPort-PHdr: 9a23:AAXzhRNt4z/N00EAgYcl6mtUPXoX/o7sNwtQ0KIMzox0Kfz7rarrMEGX3/hxlliBBdydsKIfzbeH+P28EUU7or+/81k6OKRWUBEEjchE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i760zceF13FOBZvIaytQ8iJ35/xirH5psGbSj4LrQT+SIs6FA+xowTVu5teqqpZAYF19CH0pGBVcf9d32JiKAHbtR/94sCt4MwrqHwI6LoJvvRNWqTifqk+UacQTHF/azh0t4XXskzhRACW+3YHGkofiABJDBXIpEX1V43rsyTnu8J40TWae8v/QrclUHG/qa5gDh3w3nQpLTk8pUrXkM1rkKVDoCWBORNy2caAa4GPNeFiebvdO9MdSGVMRO5NSmlLD5m4bo1JA+dXbrUQlJX0u1Zb9Uj2PgKrHu66j2YQ3nI= Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=christoph.hoeger@tu-berlin.de; spf=None smtp.mailfrom=christoph.hoeger@tu-berlin.de; spf=None smtp.helo=postmaster@mail.tu-berlin.de 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: A0BKAQDYjdxVnCEHlYJdDgiDWWmDJbxnhXsCgTM7EQEBAQEBAQEBEAEBAQEBCAsJCSEugh2CBwEBAgEBIw8BRQEFCwsaAgUWCwICCQMCAQIBRQYNBgIBAYgiCA2ybJUZAQEIIoEiijWFCgeCaYFDBZU3hQaJNkaGYiaNUoNqg2ZAbwEBgkoBAQE X-IPAS-Result: A0BKAQDYjdxVnCEHlYJdDgiDWWmDJbxnhXsCgTM7EQEBAQEBAQEBEAEBAQEBCAsJCSEugh2CBwEBAgEBIw8BRQEFCwsaAgUWCwICCQMCAQIBRQYNBgIBAYgiCA2ybJUZAQEIIoEiijWFCgeCaYFDBZU3hQaJNkaGYiaNUoNqg2ZAbwEBgkoBAQE X-IronPort-AV: E=Sophos;i="5.15,746,1432591200"; d="scan'208";a="143765683" Received: from mail.tu-berlin.de ([130.149.7.33]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Aug 2015 17:47:56 +0200 X-tubIT-Incoming-IP: 130.149.172.228 Received: from brego.uebb.tu-berlin.de ([130.149.172.228]) by mail.tu-berlin.de (exim-4.76/mailfrontend-5) with esmtpsa [UNKNOWN:AES128-SHA:128] id 1ZUGS2-00063h-8M; Tue, 25 Aug 2015 17:47:55 +0200 References: <55D827DB.3010506@tu-berlin.de> <55D85FE7.2050001@tu-berlin.de> <0D467B24-3C94-4640-8264-85BE5312EB55@math.nagoya-u.ac.jp> <55DAB843.5010800@tu-berlin.de> <55DAEEDA.6020709@tu-berlin.de> <3A6D9855-8FCD-4345-983D-011DD5138C0E@math.nagoya-u.ac.jp> To: Jacques Garrigue Cc: caml users From: =?UTF-8?Q?Christoph_H=c3=b6ger?= X-Enigmail-Draft-Status: N1110 Organization: =?UTF-8?Q?Technische_Universit=c3=a4t_Berlin?= Message-ID: <55DC8E2A.7030101@tu-berlin.de> Date: Tue, 25 Aug 2015 17:47:54 +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: <3A6D9855-8FCD-4345-983D-011DD5138C0E@math.nagoya-u.ac.jp> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] Expansion of type-constructors in ctype.ml Am 25.08.2015 um 16:02 schrieb Jacques Garrigue: > Do you mean that modifying moregen and eqtype (but not unify) > in a conservative way would be enough to solve your problem? At least until now, it seems to solve it. I can compile my ~12k classes in ~20min now. I expect the number of classes to decrease while I optimize the output of my compiler and their size to increase while I add more features. So the best bet is that the performance will stay the same, unless I encounter some more performance problems. Btw: Is there a place/format to discuss concrete proposed patches? This list seems to be more on the user's side. > Then indeed we could do that. > At least your code for eqtype seems fine. For moregen, this is not sufficient, due to non-local side effects. > By the way, we should keep your example around to prevent regressions. Feel free to add the example wherever you want. I can also open a bug in mantis if you think that is appropriate. Do you have any insights on what could be done for moregen? > You should read the following paper: > http://www.math.nagoya-u.ac.jp/~garrigue/papers/injectivity.pdf Thanks. Will do. > may_pos and may_neg are both unset (i.e. nothing is set) => no need to recurse > inj is set => must recurse > otherwise => must expand Sounds like inj is what I want for my concrete case. I recon there is no flag yet to manually set it. Do you know of a trick to force the inference mechanism to do so? And by "no need to recurse" you mean that this argument could be left out (i.e. replaced by unit)? -- 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