From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <loup.vaillant@gmail.com>
X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr
X-Spam-Level: *
X-Spam-Status: No, score=1.0 required=5.0 tests=AWL,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 discorde.inria.fr (discorde.inria.fr [192.93.2.38])
	by yquem.inria.fr (Postfix) with ESMTP id 2B47CBC0A
	for <caml-list@yquem.inria.fr>; Wed,  4 Apr 2007 14:54:30 +0200 (CEST)
Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241])
	by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l34CsSdZ004198
	for <caml-list@yquem.inria.fr>; Wed, 4 Apr 2007 14:54:29 +0200
Received: by an-out-0708.google.com with SMTP id c24so220683ana
        for <caml-list@yquem.inria.fr>; Wed, 04 Apr 2007 05:54:28 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Jcf/wSTeJwAHkpf9L9hRY+/pwjQPgM7u7UYekSB0xM7ysHIop0OERmVSyf6JZsM+h1Cu4umVQm0vE9zPIVtdyvC2NW+yYFNDiIAAmOsmfNTFzNc3Hvr1QXiHdXy2QYQdxMDJAqln+Fo+PP6UNd+N+wVJZtgaEs3o/lSgIQC31aY=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=BoP95B/q/LzFDIHtrFoNeWHO+buyZE6BPhs824mRAUrzaJZ6/dLpbzP+4+YJ08RP6tZ1cDmK10k9ou7upnkomyMMxhaZhPupF396iApdhJ+Xe7MG95WvhktTkx9MzzCvvEStudIj1E0xrzENCot7i2wwEFLryatcYG4ePpK+3VM=
Received: by 10.100.177.16 with SMTP id z16mr363861ane.1175691268215;
        Wed, 04 Apr 2007 05:54:28 -0700 (PDT)
Received: by 10.100.111.13 with HTTP; Wed, 4 Apr 2007 05:54:28 -0700 (PDT)
Message-ID: <6f9f8f4a0704040554j7b24a125ta11537459cb7f503@mail.gmail.com>
Date: Wed, 4 Apr 2007 14:54:28 +0200
From: "Loup Vaillant" <loup.vaillant@gmail.com>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Polymorphic recursion
In-Reply-To: <46133740.3070305@inria.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <6f9f8f4a0704030959l8ebb155g8532e3ee6d31c66d@mail.gmail.com>
	 <46128CEE.2090704@ed.ac.uk> <46133740.3070305@inria.fr>
X-j-chkmail-Score: MSGID : 4613A004.002 on discorde : j-chkmail score : X : 0/20 1 0.000 -> 1
X-Miltered: at discorde with ID 4613A004.002 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)!
X-Spam: no; 0.00; recursion:01 syntax:01 recursive:01 frisch:01 frisch:01 recursive:01 sig:01 val:01 seq:01 struct:01 seq:01 rewriting:01 struct:01 sig:01 val:01 

Thanks, everybody.
Now, does anyone have an idea of the overheads? I can build syntactic
sugar for all three case (using my "not yet build" Lisp syntax), so
which is more efficient?

Classes?
Recursive modules?
Records?

Thanks,
Loup

2007/4/4, Alain Frisch <Alain.Frisch@inria.fr>:
> Jeremy Yallop wrote:
> > Right.  You can write polymorphic-recursive functions if you wrap them
> > in recursive modules, though:
> >
> >   module rec Size : sig val size : 'a seq -> int end = struct
> >     let rec size = function
> >       | Unit -> 0
> >       | Seq (_, b) -> 1 + 2 * Size.size b
> >   end
>
> Note that you don't even need the "rec" in this example, and that the
> same idiom would support mutually recursive functions. To make an
> automatic translation simpler, you can simply "open Size" at the
> beginning of the structure to avoid rewriting self-references in the
> function's body. To support local definitions, you can of course rely on
> local modules:
>
> let rec f : 'a 'b. t = E1 in E2
>
> becomes:
>
> let module X = struct
>   module rec Y : sig val f : t end = struct
>     open Y
>     let f = E1
>   end
>   open Y
>   let v = E2
> end in
> X.v
>
> However, this encoding has an important drawback: you cannot use type
> variables currently in scope in t, E1, E2 (as a consequence, we don't
> need to explicitly quantify over variables in the function prototype,
> the encoding forces all the variables in the function's type to be
> universally quantified). By changing the encoding, you can allow
> references to those type variables in E2:
>
> let f =
>  let module X = struct
>    module rec Y : sig val f : t end = struct
>      open Y
>      let f = E1
>    end
>  end in
>  X.Y.f
> in
> E2
>
>
> -- Alain
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>