From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 56699BBAF for ; Fri, 16 May 2008 20:26:15 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8CAJduLUjAXQImiGdsb2JhbACDH48JAQEBDyCVU4Ve X-IronPort-AV: E=Sophos;i="4.27,498,1204498800"; d="scan'208";a="10806628" Received: from discorde.inria.fr ([192.93.2.38]) by mail2-smtp-roc.national.inria.fr with ESMTP; 16 May 2008 20:26:15 +0200 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m4GIQEos024210 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 16 May 2008 20:26:15 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlICAFtuLUjRVcivc2dsb2JhbACDH48JAQoFBAQJDwWVTYVe X-IronPort-AV: E=Sophos;i="4.27,498,1204498800"; d="scan'208";a="12677836" Received: from wf-out-1314.google.com ([209.85.200.175]) by mail3-smtp-sop.national.inria.fr with ESMTP; 16 May 2008 20:26:13 +0200 Received: by wf-out-1314.google.com with SMTP id 25so288201wfa.0 for ; Fri, 16 May 2008 11:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=reEBdC7tyT9T3JP1mZb7HeAu9cY9oFs93V1/p4cTAmI=; b=Maviy8IZot7AR0N//soi1QeEzXmIulUt/kWYjG6L4itcAAfuDexJHp2l6Jj0ShWdNCGksJHDwD60Y+mr9rrTAFTMWlwB38+sk7d9r+J8BUtEsrNzPz9KBDj0cnX4sndpfaWOtVmiPyaycIF8tLDs+WfNmZtXhzswSBSuhSuso0E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=psReJss1OSaM49suoApDE4FP8sK+BAuSc4sV6iUHjrvtk4bYkUzGywx54VbiCPApr7JwHcXP0DkRssI1AJP36vKHx5yDdI9h3ZYvdvjhL1I99wcXoNpQeaKXP18etzqn1jPPmCSlIBX0xG5eN+wXhwZ72AycE5oZp6bU63s8++E= Received: by 10.142.213.9 with SMTP id l9mr1640555wfg.104.1210962372546; Fri, 16 May 2008 11:26:12 -0700 (PDT) Received: by 10.143.17.15 with HTTP; Fri, 16 May 2008 11:26:12 -0700 (PDT) Message-ID: Date: Fri, 16 May 2008 14:26:12 -0400 From: "Markus Mottl" To: ocaml Subject: Problem specializing types in signatures MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Miltered: at discorde with ID 482DD1C6.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; markus:01 mottl:01 markus:01 mottl:01 sig:01 sig:01 syntax:01 pitfalls:01 ocaml:01 node:01 ocaml:01 blog:98 signatures:01 signatures:01 namely:02 Hi, I have just recently run into a slightly annoying problem specializing types in signatures, e.g.: module type A = sig type t end module type B = sig include A with type t = X end The above will lead to a syntax error, because sum types, as well as record types, cannot be used in the definition of t in the "with t = ..." part. But there does not seem to be an obvious reason why this shouldn't be allowed, because one can always just manually replace "include A" with "A" and add the corresponding right hand side of the type. We cannot specify that e.g. a function returns a record by just placing the type definition of the record in the signature of the function. We first have to bind the record definition to a type name, otherwise type errors would be much harder to understand. But this is not the case here: we already have a type name to refer to, namely "t" so this explanation for this behavior doesn't seem to apply. Shouldn't it be possible to relax the language rules here to allow direct definitions of types? Or am I missing potential pitfalls here? Btw., a clumsy workaround requiring the introduction of a dummy type is the following: module type B = sig type x = X include A with type t = x end Regards, Markus P.S.: A commentator on one of our blog articles also ran into a similar issue: http://ocaml.janestcapital.com/?q=node/26 -- Markus Mottl http://www.ocaml.info markus.mottl@gmail.com