From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <milanst@gmail.com>
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 A4EC37FBEB
	for <caml-list@sympa.inria.fr>; Wed, 14 Jan 2015 17:33:31 +0100 (CET)
Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender
  authenticity information available from domain of
  milanst@gmail.com) identity=pra; client-ip=209.85.213.172;
  receiver=mail3-smtp-sop.national.inria.fr;
  envelope-from="milanst@gmail.com";
  x-sender="milanst@gmail.com"; x-conformance=sidf_compatible
Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of
  milanst@gmail.com designates 209.85.213.172 as permitted
  sender) identity=mailfrom; client-ip=209.85.213.172;
  receiver=mail3-smtp-sop.national.inria.fr;
  envelope-from="milanst@gmail.com";
  x-sender="milanst@gmail.com"; x-conformance=sidf_compatible;
  x-record-type="v=spf1"
Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender
  authenticity information available from domain of
  postmaster@mail-ig0-f172.google.com) identity=helo;
  client-ip=209.85.213.172;
  receiver=mail3-smtp-sop.national.inria.fr;
  envelope-from="milanst@gmail.com";
  x-sender="postmaster@mail-ig0-f172.google.com";
  x-conformance=sidf_compatible
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiIBAAaatlTRVdWsm2dsb2JhbABbDoQiBIMByHICgQ4HQwEBAQEBEQEBAQEBBgsLCRQuhA0BAQMBEhEdARsQCgMBAwELBgULDwImAgIiAREBBQEcBjWHdQEDCQixGT4xiy6Ba4J3iwQKGScNVIMPAQEBAQEFAQEBAQEXAQUOgROOWAeCaIFBBYlmjWmQMhIjgQwJg1NbIDGCQwEBAQ
X-IPAS-Result: AiIBAAaatlTRVdWsm2dsb2JhbABbDoQiBIMByHICgQ4HQwEBAQEBEQEBAQEBBgsLCRQuhA0BAQMBEhEdARsQCgMBAwELBgULDwImAgIiAREBBQEcBjWHdQEDCQixGT4xiy6Ba4J3iwQKGScNVIMPAQEBAQEFAQEBAQEXAQUOgROOWAeCaIFBBYlmjWmQMhIjgQwJg1NbIDGCQwEBAQ
X-IronPort-AV: E=Sophos;i="5.07,756,1413237600"; 
   d="scan'208";a="96421521"
Received: from mail-ig0-f172.google.com ([209.85.213.172])
  by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 14 Jan 2015 17:33:30 +0100
Received: by mail-ig0-f172.google.com with SMTP id l13so10348373iga.5
        for <caml-list@inria.fr>; Wed, 14 Jan 2015 08:33:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc:content-type;
        bh=G9e5QbtyidBmOSMMYx4WiCVniSacTcZkCjnC0kK6JBY=;
        b=iElVxmuk7wgcyaaSrkogRWx8MTm/rNRVbIOoGdM9bFJszvR2nnbP2Ycv+fHjrZgaoN
         C8F8jvrCnu5RMsu3iMi0xTcsFbRoPUiNFAENUOcl41RTRvZVN1Gb24q8T8JZn2DdZy38
         0cemE+XEroUyQKv2jOx4Ya0d+X5w4/And0+0R9nwr7NOU/JmhlctoZKwp+9+W+7UcNUB
         SDF3wv3K5RIMiftaC/fHEg/W/+0S/mEomYdcLm3492RH2SQk9JFzihHnG7jRZQ9ZLk4A
         z2pIKdG/hqkvtCERzbwL4Fd9woB2LjPCymtIXBOwL4xAKwiAw4ID5yJsrisJqmQetc7m
         H6gg==
X-Received: by 10.107.133.142 with SMTP id p14mr5207514ioi.6.1421253209600;
 Wed, 14 Jan 2015 08:33:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.65.226 with HTTP; Wed, 14 Jan 2015 08:32:49 -0800 (PST)
In-Reply-To: <ED9C9FB2-9BFF-423A-85C4-012BEB381928@math.nagoya-u.ac.jp>
References: <CAHR=Vkx1Lb43qh5QtcnKM2tw=64m6NuU8xsd0CoFR5P7tP2X8g@mail.gmail.com>
 <877fwqqua0.fsf@study.localdomain> <CAKR7PS9AeWZbMkU1oYdWD3N96znwJYMJF2Hygbfr0kxRwcdhwQ@mail.gmail.com>
 <87twzup6ie.fsf@study.localdomain> <ED9C9FB2-9BFF-423A-85C4-012BEB381928@math.nagoya-u.ac.jp>
From: =?UTF-8?Q?Milan_Stanojevi=C4=87?= <milanst@gmail.com>
Date: Wed, 14 Jan 2015 11:32:49 -0500
Message-ID: <CAKR7PS_GGqqE-NYhHuMCBs+Nb7399P5FxaHAuJwC+F41g2rLNA@mail.gmail.com>
To: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
Cc: Leo P White <lpw25@cam.ac.uk>, Thomas Braibant <thomas.braibant@gmail.com>, 
	OCaml Mailing List <caml-list@inria.fr>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [Caml-list] Quizz

> The main problem is not so much syntax, as the fact it would require to make
> all definitions in the Types module mutually recursive. Not only that, but
> operations like path substitution need to be mutually recursive in the same
> way. So the question is whether the small gain in flexibility is worth making the
> implementation more complex.
> (Note that an extra gain is that it becomes possible to expand a module type
> definition when leaving its scope)

In my work I mostly just wanted to be able to just do something like
(module M : Intable with type t = t), i.e just specializing existing
module type with "with type =" or "with type :=".
Is this special case any easier to implement?