From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by c5ff346549e7 (Postfix) with ESMTPS id E5B065D5 for ; Tue, 26 Feb 2019 06:39:53 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.58,414,1544482800"; d="scan'208";a="370884642" Received: from sympa.inria.fr ([193.51.193.213]) by mail2-relais-roc.national.inria.fr with ESMTP; 26 Feb 2019 07:39:52 +0100 Received: by sympa.inria.fr (Postfix, from userid 20132) id 65F84825FC; Tue, 26 Feb 2019 07:39:52 +0100 (CET) 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 7B756825BD for ; Tue, 26 Feb 2019 07:39:38 +0100 (CET) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=garrigue@math.nagoya-u.ac.jp; spf=None smtp.mailfrom=garrigue@math.nagoya-u.ac.jp; spf=None smtp.helo=postmaster@ms.math.nagoya-u.ac.jp IronPort-PHdr: =?us-ascii?q?9a23=3Acat0YRcmCV2GoL6I56DtiMudlGMj4u6mDksu8pMi?= =?us-ascii?q?zoh2WeGdxcS5Yh7h7PlgxGXEQZ/co6odzbaO4+a4ASQp2tWoiDg6aptCVhsI24?= =?us-ascii?q?09vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFRrhKAF7?= =?us-ascii?q?Ovr6GpLIj8Swyuu+54Dfbx9HiTahYr5+Ngm6oRnMvcQKnIVuLbo8xAHUqXVSYe?= =?us-ascii?q?RWwm1oJVOXnxni48q74YBu/SdNtf8/7sBMSar1cbg2QrxeFzQmLns65Nb3uhnZ?= =?us-ascii?q?TAuA/WUTX2MLmRdVGQfF7RX6XpDssivms+d2xSeXMdHqQb0yRD+v9LlgRgP2hy?= =?us-ascii?q?gbNj456GDXhdJ2jKJHuxKquhhzz5fJbI2JKPZye6XQds4YS2VcRMZcTzBODYyh?= =?us-ascii?q?YYUPDeUPM+lWoYrzp1UQqhWzHhWsBPrqyjNUhn/6wa833uI8Gg/GxgwgGNcOvW?= =?us-ascii?q?zQotrvKKgSSP21w7fTzT7ebv1Zwy396JLJchAuvPGDQ697fM3eyUY1DQPFlFSQ?= =?us-ascii?q?qYP4PzyLzekNtnKU7/ZgVe61jW4osQ5xoj+vx8g2k4XJm5gZxUrY+iljwoY1Pc?= =?us-ascii?q?S1RUhmatCnCJtdrzyWOoV4T884Qmxkojs2x7MatZKhYSQG1Ywryh7cZvCdboSF?= =?us-ascii?q?4hHuWPyMLTtmh39pYq+zihaw/EWm1+byTNO70ExQoSpAitTMtm4C1xjU6sWfT/?= =?us-ascii?q?t95V2t2TOV2ADP6uFIO0Y0mrDUK54mwr8/jIMfsVnZEiDshEr6lq2Wdl089uip?= =?us-ascii?q?7eTofKnmq4eBO4J6hAzyKKUjltaiDek2LgQCRXWX9fmk2L3m50L5QbFKjvMskq?= =?us-ascii?q?netZDXPcsbqbSjAw9P04Yj5Au/ACm93dQdh3YHMFJFdAiBj4fzNFHOJ/D5Au2m?= =?us-ascii?q?j1Sxijtk3ezJMqfjApXVNnTDiqvufa5h605Azwo+1cxQ6IhRCrEFOf7zXk7xtM?= =?us-ascii?q?fEDhIiKAy1w+PnCM1n2Y8EWGKPBLWZMKLIvlOS6OIvObrEWIhAmDv7J+Ik5LbE?= =?us-ascii?q?ing80QsdcK+lx5oUQGy/BvNnZV2eZmOqidAERzQkpA07Gc7jg0SfXCUbSH+oRa?= =?us-ascii?q?Mz+zxzXI2vF53CSZ2gqLmIwCf9GJRZYXFPT03KGHyudZ3SCKREUz6bPsI0ym9M?= =?us-ascii?q?brOmUYJ0kEj27FarmYoiFfLd/2gjjbym0dF04+PJkhRorG5xBtidlWeEQGZlly?= =?us-ascii?q?YVATY9mqJn8xQklgWzlJNgivkdLuR9outTW11jZ5vV0+w8Ddn9XRPIO8rPQV3g?= =?us-ascii?q?QM30WWhsHOJ0+McHZgNGI/vnjh3H2HD2UboO0bmCGJxy9KvT2Gn4Yts7wn2A1r?= =?us-ascii?q?Fz11Q=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DnAgBZ3nRclwuCBoVkHAEBAQQBAQcEA?= =?us-ascii?q?QGBZYJuTiASJ4QIiHmnIgEMhGwChCgGBjQSAQMBAQIBAQEBARMBAQEBAQgWBkw?= =?us-ascii?q?MgjopAYJnBiMEGQEBNwEPCxoCJgICVwYTgyCBcqpWcXwzgngBAQWCRYMEIYFKC?= =?us-ascii?q?IELi1SBf4E4H4IeLoUBgwoxgiaHbAeJapIHCZJoGYptiCqZf4MTgV6Bd004Oyo?= =?us-ascii?q?BgkE+gV4ahlqHXDAzkD4BAQ?= X-IPAS-Result: =?us-ascii?q?A0DnAgBZ3nRclwuCBoVkHAEBAQQBAQcEAQGBZYJuTiASJ4Q?= =?us-ascii?q?IiHmnIgEMhGwChCgGBjQSAQMBAQIBAQEBARMBAQEBAQgWBkwMgjopAYJnBiMEG?= =?us-ascii?q?QEBNwEPCxoCJgICVwYTgyCBcqpWcXwzgngBAQWCRYMEIYFKCIELi1SBf4E4H4I?= =?us-ascii?q?eLoUBgwoxgiaHbAeJapIHCZJoGYptiCqZf4MTgV6Bd004OyoBgkE+gV4ahlqHX?= =?us-ascii?q?DAzkD4BAQ?= X-IronPort-AV: E=Sophos;i="5.58,414,1544482800"; d="scan'208";a="297320917" Received: from bsd20.math.nagoya-u.ac.jp (HELO ms.math.nagoya-u.ac.jp) ([133.6.130.11]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2019 07:39:36 +0100 Received: from [192.168.0.12] (58x158x128x157.ap58.ftth.ucom.ne.jp [58.158.128.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ms.math.nagoya-u.ac.jp (Postfix) with ESMTPSA id E7038A8E95F; Tue, 26 Feb 2019 15:39:32 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=math.nagoya-u.ac.jp; s=20160220; t=1551163173; bh=XSFe/HWR2fC7bPNODwCy5XYsSlywO81A9Jb3eIWuIRs=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=c9YnXRxHeAxmokM8qn87MLamEqaq7w8uWzbe3XwJ7iscVPL4/kmlepXEve13P2IrH bjVWxLgNtlxmJ4EPJpxvVxvLRtvSo46EnW/ivYAQUGtSc57scjkgusNYX7r0PzMz4F N63/hhCtR+KtcYuHDaadPu40DVGuPpjBjiRFCCy0= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Jacques Garrigue In-Reply-To: <20190226062341.t35u2tz5tole2jyv@topoi.pooq.com> Date: Tue, 26 Feb 2019 15:39:24 +0900 Cc: Mailing List OCaml Content-Transfer-Encoding: quoted-printable Message-Id: References: <20190226062341.t35u2tz5tole2jyv@topoi.pooq.com> To: Hendrik Boom X-Mailer: Apple Mail (2.3445.102.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (ms.math.nagoya-u.ac.jp [0.0.0.0]); Tue, 26 Feb 2019 15:39:32 +0900 (JST) X-Virus-Scanned: clamav-milter 0.99.2 at bsdserver20 X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on bsdserver20.math.nagoya-u.ac.jp Subject: Re: [Caml-list] An awkwardness with type parameters Reply-To: Jacques Garrigue X-Loop: caml-list@inria.fr X-Sequence: 17371 Errors-to: caml-list-owner@inria.fr Precedence: list Precedence: bulk Sender: caml-list-request@inria.fr X-no-archive: yes List-Id: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 2019/02/26 15:23, Hendrik Boom : >=20 > I have a (broken) function definition starting: >=20 > let mixfix : 'token1 'phrase1. > ('token1, 'phrase1, ('token1, 'phrase1) Phrasestream.phrasestream) = grammar > -> ('token1, 'phrase1) parser > =3D fun gram -> ( > ... >=20 > It goes o for a hundred-odd lines. > The type-parameterized types Phrasestream.phrasestream, grammar, and = parser =20 > have been previously defined, and there are also operations defined on = these > types. >=20 > The problem I'm having is that the OCaml type-checker ends up = identifying > the type parameters 'token1 an 'phrase1 because of type errors I've = made in > the body of the mixfix function. Somewhere I ended up using an > operator that's supposed to work on values of type 'token1 > on a value of type 'phrase1 instead, and identification of 'token1 and=20= > 'phrase1 is the natural result. >=20 > Is there some way of forcing the type checker to treat 'token1 and=20 > 'phrase1 as different types so that I can get meaningful type errors > at the point were they occur? You can use locally abstract types, which are often used with GADTs but = are not restricted to them: let mixfix : type token1 phrase1. (token1, phrase1, (token1, phrase1) Phrasestream.phrasestream) = grammar -> (token1, phrase1) parser =3D fun gram -> ( =E2=80=A6 This is the same as the type you wrote, but additionally prevents the = types from being instantiated inside the definition of mixdix. Jacques Garrigue=