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=1.8 required=5.0 tests=AWL,DNS_FROM_RFC_POST, HTML_MESSAGE,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id F2E13BBAF for ; Sun, 19 Apr 2009 23:36:14 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAFs260nRVdmeWmdsb2JhbACCIy6TKTUBFgoLBxICpXOBCY4oAQMBA4N6Bg X-IronPort-AV: E=Sophos;i="4.40,213,1238968800"; d="scan'208";a="26482141" Received: from mail-gx0-f158.google.com ([209.85.217.158]) by mail3-smtp-sop.national.inria.fr with ESMTP; 19 Apr 2009 23:36:14 +0200 Received: by gxk2 with SMTP id 2so1075197gxk.3 for ; Sun, 19 Apr 2009 14:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=px6lJrFVbCKsl3t654hjHTurC0VInxqbq/2iaQB34hM=; b=WnJl7FbIGueDcwsVof57U3WlDXwvgX27J2egrYkfZi3iOFlzlJyKLG8gtN/vW+ma/1 5uQdS968itJPd4tls0Ys+8zgjPeBuDA2JSZHwu0ElQ/qPwpFaOpm/OZ6hTIF9p5l+WWL LcmwavALmasHxMwygV8R/VTN0FjVPCw2qprjE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=x+vF2+vA2TCBnNCYOWARbNn+mIjStpGNstZr4P4COH6sU72ED6oAykmgQUOPYmNSgy 7K3N9G0+JFd+j3Lu2CeM486hfTTJjHJ6UIVnJJPp9muOpPfLGubHsNGhqfnwndIaFmUu pEpqO4WodQ8ScYzHrtP2XhhT9ZmabYMAvCs90= MIME-Version: 1.0 Received: by 10.90.63.6 with SMTP id l6mr6446106aga.46.1240176973173; Sun, 19 Apr 2009 14:36:13 -0700 (PDT) In-Reply-To: <49E9E195.6030603@ens-lyon.org> References: <49E9E195.6030603@ens-lyon.org> Date: Sun, 19 Apr 2009 17:36:12 -0400 Message-ID: Subject: Re: [Caml-list] Extending modules and signatures From: Ashish Agarwal To: Martin Jambon Cc: Peter Hawkins , caml-list@yquem.inria.fr Content-Type: multipart/alternative; boundary=00163616451bf1d53c0467ef33eb X-Spam: no; 0.00; mli:01 compiler:01 mli:01 ens-lyon:01 compiler:01 ens-lyon:01 1975:98 2009:98 2009:98 wrote:01 wrote:01 signatures:01 naming:01 naming:01 caml-list:01 --00163616451bf1d53c0467ef33eb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > The module type exists, it's just that it doesn't have a name. Right, thanks for the clarification. > let x = (123, "abc") > does not define "type x = int * string" either. True, but I think the expectations are different for module types. A file a.ml creates a module named A, and it seems natural to expect a.mli to create a module type A. I find it inconsistent that it does not. Further, if you wanted to name the above type, it is easy, just write "type x = int * string". The corresponding solution to naming module types is burdensome. You have to define it within another module, introducing an unnecessary layer into your module hierarchy. Also that doesn't help you when using somebody else's library. Having the compiler introduce module type names automatically from mli files would be very helpful, and I don't see any disadvantages. On Sat, Apr 18, 2009 at 10:20 AM, Martin Jambon wrote: > Ashish Agarwal wrote: > > This is a commonly requested feature. > > Ah. > > > One issue is that a file a.ml > > creates a module A. However, a file a.mli does not create > > a module type A. I'm not sure why this is the case. Does anyone know if > > there is a specific reason? > > The module type exists, it's just that it doesn't have a name. > > let x = (123, "abc") > > does not define "type x = int * string" either. > > > > Martin > > -- > http://mjambon.com/ > --00163616451bf1d53c0467ef33eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >= The module type exists, it's just that it doesn't have a name.

Right, thanks for the=A0clarification.

=
=
> let x =3D (123, "abc")
> does not define "type x =3D int * string" either.

True, but I think the expectations are differe= nt for module types. A file a.ml creates a modu= le named A, and it seems natural to expect a.mli to create a module type A.= I find it inconsistent that it does not.

Further, if you wanted to name the above type, it is ea= sy, just write "type x =3D int * string". The corresponding solut= ion to naming module types is burdensome. You have to define it within anot= her module, introducing an unnecessary layer into your module hierarchy. Al= so that doesn't help you when using somebody else's library.

Having the compiler introduce module type names automat= ically from mli files would be very helpful, and I don't see any disadv= antages.



On Sat, Apr 18, 2009 at 10:20 = AM, Martin Jambon <martin.jambon@ens-lyon.org> wrote:
Ashish Agarwal wrote:
> This is a commonly requested feature.

Ah.

> One issue is that a file a.m= l
> <http://a.ml>= ; creates a module A. However, a file a.mli does not create
> a module type A. I'm not sure why this is the ca= se. Does anyone know if
> there is a specific reason?

The module type exists, it's just that it doesn't have a name= .

=A0let x =3D (123, "abc")

does not define "type x =3D int * string" either.



Martin

--
http://mjambon.com/

--00163616451bf1d53c0467ef33eb--