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 D33C87F0A3 for ; Sat, 22 Aug 2015 13:41:30 +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: A0BUAQBoX9hVnCEHlYJeg29pgyW8MIYDAoEpTAEBAQEBARIBAQEBAQYNCQkhLoQkAQEEIwQLAUURCxgCAgUWCwICCQMCAQIBRQYNBgIBAYgqBK4YlT0sgSKKNYURgmmBQwWVNIUFiXuGYJFdhCVvgkwBAQE X-IPAS-Result: A0BUAQBoX9hVnCEHlYJeg29pgyW8MIYDAoEpTAEBAQEBARIBAQEBAQYNCQkhLoQkAQEEIwQLAUURCxgCAgUWCwICCQMCAQIBRQYNBgIBAYgqBK4YlT0sgSKKNYURgmmBQwWVNIUFiXuGYJFdhCVvgkwBAQE X-IronPort-AV: E=Sophos;i="5.15,728,1432591200"; d="scan'208";a="143510238" Received: from mail.tu-berlin.de ([130.149.7.33]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Aug 2015 13:41:30 +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-7) with esmtpsa [UNKNOWN:AES128-SHA:128] for id 1ZT7Au-0002GY-0a; Sat, 22 Aug 2015 13:41:29 +0200 To: caml users References: <55D827DB.3010506@tu-berlin.de> From: =?UTF-8?Q?Christoph_H=c3=b6ger?= X-Enigmail-Draft-Status: N1110 Organization: =?UTF-8?Q?Technische_Universit=c3=a4t_Berlin?= Message-ID: <55D85FE7.2050001@tu-berlin.de> Date: Sat, 22 Aug 2015 13:41:27 +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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.8.22.113017 X-PMX-Spam: Gauge=IIIIIII, Probability=0%, Report='' Subject: Re: [Caml-list] Expansion of type-constructors in ctype.ml Right, that is a good point. That means unification _is_ a special issue. How about moregen? However, I wonder what the true special case is, here: Does this only apply to type-constructors where some argument is left unused? So if I would apply my optimization only to constructors where all arguments appear on the right-hand side (how would I check that?) would that help? I am facing a real issue here, because my thesis depends on the compilation of 12k such classes into OCaml, and I need to demonstrate its practical feasibility. So patching the compiler is not a big issue (since I find it quite readable). However, I would prefer to upstream these changes, of course and this would require some mentoring (API, code style etc.) Am 22.08.2015 um 11:23 schrieb Jeremy Yallop: > On 22 August 2015 at 08:42, Christoph Höger > wrote: >> 1. In the case of equality, it seems fairly simple. Iff the path of two >> constructors is the same and both argument lists are equal, the types >> are equal, right? > > "If", but not "iff", unless you expand first. Consider > > type 'a t = unit > > Then 'int t' and 'float t' should be considered equal, since they both > expand to 'unit', even though the argument lists are unequal > >> 2. In the case of unification, if both paths are the same, the argument >> lists are of the same length, we can directly unify the arguments, right? > > Again, you need to expand the path first. Consider the following > function, using the same definition of 't' as above: > > fun (a : 'a) (b : 'b) -> > let c : 'a t = () > and d : 'b t = () in > ignore [c; d]; > > The last line involves unifying the types 'a t and 'b t. Unifying the > type arguments 'a and 'b results in the following type for the > function: > > 'a -> 'a -> unit > > Expanding 't' before unifying means that 'a and 'b are not unified, > and the function can be given the more general type: > > 'a -> 'b -> 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