From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105])
	by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p89NVsoA003811
	for <caml-list@sympa-roc.inria.fr>; Sat, 10 Sep 2011 01:31:54 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmABANWgak7RVaE2kGdsb2JhbABChFWjOwgUAQEBAQkJDQcUBCKBUgEBAQEDEgIPBBEIARscAQEDDAYFCw0CAgUWCwICCQMCAQIBEREBBQEcBg0BBwEBHodWmmwKinxCgleFSjuIbQIDBoEmhDGBEQSTOIUVgSmGND2DbQ
X-IronPort-AV: E=Sophos;i="4.68,358,1312149600"; 
   d="scan'208";a="108356393"
Received: from mail-fx0-f54.google.com ([209.85.161.54])
  by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 10 Sep 2011 01:31:49 +0200
Received: by fxe4 with SMTP id 4so5604643fxe.27
        for <caml-list@inria.fr>; Fri, 09 Sep 2011 16:31:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        bh=huUvf4Y/9g86U15cFWMMb6sOLSMyjwZmEIsGppQr64M=;
        b=INxQ2T8R/01EH8aFy8RPJAAd7EnhRW0vnrrEeU+j2SKvwQ03dLSo0spxPwiDBFZoH2
         iABTLiTeYfc+GhqCmUpr/s/Xepl2ngouPWjY7M9SHn0CSeZfPllK4G/mivtbr87bVkW5
         2F/3JZIruDOMTXVC66shQrd9o5Y6Bp2/i/u6E=
Received: by 10.223.6.91 with SMTP id 27mr125340fay.115.1315611108605;
        Fri, 09 Sep 2011 16:31:48 -0700 (PDT)
Received: from [192.168.0.1] (ramona.xulforum.org [82.243.127.33])
        by mx.google.com with ESMTPS id a19sm3521201fac.6.2011.09.09.16.31.46
        (version=SSLv3 cipher=OTHER);
        Fri, 09 Sep 2011 16:31:47 -0700 (PDT)
Message-ID: <4E6AA1E1.9050307@gmail.com>
Date: Sat, 10 Sep 2011 01:31:45 +0200
From: Jonathan Protzenko <jonathan.protzenko@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110824 Thunderbird/9.0a1
MIME-Version: 1.0
To: Anthony Tavener <anthony.tavener@gmail.com>
CC: caml-list@inria.fr
References: <CAN=ouMSM0SaKnKs3WCFk=yH5yLdWoToi3YtW_i5hTT300CpaKw@mail.gmail.com>
In-Reply-To: <CAN=ouMSM0SaKnKs3WCFk=yH5yLdWoToi3YtW_i5hTT300CpaKw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Caml-list] Mutually recursive closures?

You can use equirecursive types, which can be enabled through the 
-rectypes command-line switch. With that option, your example above 
type-checks. However, these are not enabled by default for a variety of 
reasons, the most important one being it makes it much easier to shoot 
yourself in the foot.

Cheers,

jonathan

On Sat 10 Sep 2011 01:14:46 AM CEST, Anthony Tavener wrote:
> I was considering returning a couple of closures to help organize my 
> UI code, essentially representing current UI mode by one of these 
> closures. But then I run into a problem because the types are infinite 
> (returns a function, which returns a function, ...)
>
> A simplified example:
>
> # let rec a () = printf "state a\n"; b
>        and b () = printf "state b\n"; a
>
> Error: This expression has type unit -> unit -> 'a
>        but an expression was expected of type 'a
>
>
> Is there a way I can do this? To express (or 'hide') the cyclic nature 
> of the type resolution?
>
> I've considered using continuations, but that seems heavy-weight for 
> what I'm looking to do. And as far as I can tell I'd need to leverage 
> Oleg's delimcc (which I'd love to start using and wrap my head around 
> -- but for a task worthy of it!).
>
> I can use a variant to represent states/modes and have a dispatcher 
> which runs the right code... but this introduces what feels like an 
> unnecessary layer of distraction. Returning the closure of the "next 
> state" seems straightforward, but introduces cycles into the typing. :(
>
> I'm hoping I'm missing something simple. Thank-you for any assistance!
>
>  -Tony
>