From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <lambda.q.q@gmail.com>
X-Original-To: caml-list@sympa.inria.fr
Delivered-To: caml-list@sympa.inria.fr
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by sympa.inria.fr (Postfix) with ESMTPS id A364D7F1C3
	for <caml-list@sympa.inria.fr>; Wed, 28 Nov 2012 04:42:42 +0100 (CET)
Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  lambda.q.q@gmail.com) identity=pra; client-ip=209.85.217.182;
  receiver=mail1-smtp-roc.national.inria.fr;
  envelope-from="lambda.q.q@gmail.com";
  x-sender="lambda.q.q@gmail.com";
  x-conformance=sidf_compatible
Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of
  lambda.q.q@gmail.com designates 209.85.217.182 as permitted
  sender) identity=mailfrom; client-ip=209.85.217.182;
  receiver=mail1-smtp-roc.national.inria.fr;
  envelope-from="lambda.q.q@gmail.com";
  x-sender="lambda.q.q@gmail.com";
  x-conformance=sidf_compatible; x-record-type="v=spf1"
Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  postmaster@mail-lb0-f182.google.com) identity=helo;
  client-ip=209.85.217.182;
  receiver=mail1-smtp-roc.national.inria.fr;
  envelope-from="lambda.q.q@gmail.com";
  x-sender="postmaster@mail-lb0-f182.google.com";
  x-conformance=sidf_compatible
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkUBALOHtVDRVdm2mGdsb2JhbAA8CcAbCBYOAQEBAQEICQ0HFCeCHgEBBAEnEwYBOAEDAQsBBQUhJQ8BBA0TAQUBIhOHewMJBgSgcI8thRInDYlOAQUMi0V7hC8DiFiLVIFVizSDMD+BV4I/
X-IronPort-AV: E=Sophos;i="4.84,175,1355094000"; 
   d="scan'208";a="183538656"
Received: from mail-lb0-f182.google.com ([209.85.217.182])
  by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 28 Nov 2012 04:42:42 +0100
Received: by mail-lb0-f182.google.com with SMTP id go10so13762656lbb.27
        for <caml-list@inria.fr>; Tue, 27 Nov 2012 19:42:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=sender:from:to:cc:subject:references:date:in-reply-to:message-id
         :user-agent:mime-version:content-type;
        bh=qNaH+zM2KzjRlkF2Z5fPjuciLv14Lxs2Qd5wpRSJPXQ=;
        b=hmEppfH3lMbK5osWZKUD+z1PfOXtXEp4x+LJPL73piHt4DBcWaKsKr4PSg8UWgBD6g
         h/mdhpD2gnQ8k6Ci6S221ZCT/Nptet/f/Y7pk0b1uqqWEHLoLskg7gJNnBXPPA1GzrN0
         /2B+yF3qMKdW0gp1QejwHeAzgipJSeBwWhwsFz2Yc5taAVmpMkuEwE/QKM0MYcUFMtDO
         xkZUO0bn23/XpXtPWqfo4z8tDubdyUu8GRBbfFln33ZyuXiknSFkEgsSmsx1pMqtlD87
         EBR9TdoO9n1bDBlV+PBspBOwv/aAZuaqgAZhqjm3THyjPxHNUMkBU0TgWVP74AMGAMBE
         yctw==
Received: by 10.112.102.130 with SMTP id fo2mr7654166lbb.35.1354074161498;
        Tue, 27 Nov 2012 19:42:41 -0800 (PST)
Received: from golf.niidar.ru.niidar.ru ([178.176.188.42])
        by mx.google.com with ESMTPS id bf3sm7702341lbb.16.2012.11.27.19.42.39
        (version=TLSv1/SSLv3 cipher=OTHER);
        Tue, 27 Nov 2012 19:42:40 -0800 (PST)
Sender: Ivan Gotovchits <lambda.q.q@gmail.com>
From: Ivan Gotovchits <ivg@ieee.org>
To: Gabriel Scherer <gabriel.scherer@gmail.com>
Cc: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>,  caml-list@inria.fr
References: <87ip8rwbsc.fsf@golf.niidar.ru>
	<1F656500-76AC-482F-BA08-A9BB8250D904@math.nagoya-u.ac.jp>
	<CAPFanBFbY8drGNzwy8y6jOaFe=6oSs26PjtcWFMuntcTv8+eCQ@mail.gmail.com>
Date: Wed, 28 Nov 2012 07:42:33 +0400
In-Reply-To: <CAPFanBFbY8drGNzwy8y6jOaFe=6oSs26PjtcWFMuntcTv8+eCQ@mail.gmail.com>
	(Gabriel Scherer's message of "Tue, 27 Nov 2012 16:59:43 +0100")
Message-ID: <87fw3uxuja.fsf@golf.niidar.ru>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [Caml-list] phantom types and identity function

Gabriel Scherer <gabriel.scherer@gmail.com> writes:

> The absence of such a variance marker means that some OCaml code is
> hard to abstract through a module boundary: in presence of the
> explicit definition, the type-checker will accept to subtype between
> any instances of the type (by simple expansion), but if you abstract
> over its definition you cannot express this property anymore. Your
> workaround corresponds to statically expressing this irrelevance
> through an exported equation, but there are (arguably somewhat
> unnatural) scenarios where this isn't convenient.

And now I'm confused much more =). Please, could you explain the
relevance between subtyping and type restriction?

When I try to restrict type [t -> t'] by the some type [r -> r'] does
the compiler checks that [r -> r'] is a subtype of [t -> t']? And even
if it does, in my example 
   [`A] t -> [`B] t

[[`A]] is clearly not a subtype of [[`B]] (and vice versa). So I do not
see how an explicit variance specification can help.


-- 
         (__) 
         (oo) 
   /------\/ 
  / |    ||   
 *  /\---/\ 
    ~~   ~~   
...."Have you mooed today?"...