From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p8AAXHsf017755 for ; Sat, 10 Sep 2011 12:33:17 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0BAFc8a07RVaE2kGdsb2JhbABCpxp3CBQBAQEBCQkNBxQEIoFSAQEBAQIBEgITGQEbHQEDAQsGBQsNLiEBAREBBQEcBhMih1SYaAqJeoFEgleFATuIbQIDBoZoBIdti06KCIJsPYQL X-IronPort-AV: E=Sophos;i="4.68,360,1312149600"; d="scan'208";a="119133816" Received: from mail-fx0-f54.google.com ([209.85.161.54]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 10 Sep 2011 12:33:12 +0200 Received: by fxe4 with SMTP id 4so6083690fxe.27 for ; Sat, 10 Sep 2011 03:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c7EQ95NzSi1uq5XJBq26Q1iqL/frbbl1Bo5NMvD4mE0=; b=KXRgJwTVKc/LFyLsZTRjPPsHz/jQ9kM4A7c2KD40naIdFdCt3V/NUX242N7jTLpRnE hnBX45RFP8kf8VE5h3vXv3CLu4Ip01KwZauimwzUuF0O04J1uhygTQzrRCwyh2BfA94x r4KUhjnyO33W7joZG3lGAUFQO8pFfmiX6/9zo= MIME-Version: 1.0 Received: by 10.223.58.13 with SMTP id e13mr1087392fah.41.1315650791840; Sat, 10 Sep 2011 03:33:11 -0700 (PDT) Received: by 10.223.109.195 with HTTP; Sat, 10 Sep 2011 03:33:11 -0700 (PDT) In-Reply-To: References: <4E6AA1E1.9050307@gmail.com> Date: Sat, 10 Sep 2011 04:33:11 -0600 Message-ID: From: Anthony Tavener To: Philippe Veber Cc: caml-list@inria.fr Content-Type: multipart/alternative; boundary=00151747583e189bc904ac93d2b5 Subject: Re: [Caml-list] Mutually recursive closures? --00151747583e189bc904ac93d2b5 Content-Type: text/plain; charset=ISO-8859-1 That's a good alternative, thanks Philippe! I might use this, but encapsulate the returned closures with the constructor since they will be of common type -- whereas the function signatures will be different, some having additional parameters. I've read more on rectypes and it's certainly not to be used lightly! On Sat, Sep 10, 2011 at 12:54 AM, Philippe Veber wrote: > You may not need the -rectypes option if you add a thin layer around your > functions: > > Objective Caml version 3.12.1 > > Findlib has been successfully loaded. Additional directives: > [...] > # type t = F of (unit -> t);; > type t = F of (unit -> t) > # let rec a = F (fun () -> print_endline "a" ; b) > and b = F (fun () -> print_endline "b" ; a);; > val a : t = F > val b : t = F > # let ( ! ) (F f) = f ();; > val ( ! ) : t -> t = > # let x1 = ! a;; > a > val x1 : t = F > # ! x1;; > b > - : t = F > > It works in this version because you're defining a brand new type, and not > using a type alias (like in type t = unit -> t). I think a record would work > too, but I think either is needed to avoid using -rectypes. > > cheers, > Philippe. > > > > > 2011/9/10 Anthony Tavener > >> Thanks Jonathan! I've seen -rectypes mentioned over the years and always >> glossed over it thinking "Ah, I'll never need that!" :P >> >> Understandable that it's a good default to have disabled. I'll experiment >> first and if I like the results I'll try to limit compiling with -rectypes >> to the smallest bit of code using it. >> >> >> On Fri, Sep 9, 2011 at 5:31 PM, Jonathan Protzenko < >> jonathan.protzenko@gmail.com> wrote: >> >>> 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 >>>> >>>> >> > --00151747583e189bc904ac93d2b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
That's a good alternative, thanks Philippe! I might use this, but = encapsulate the returned closures with the constructor since they will be o= f common type -- whereas the function signatures will be different, some ha= ving additional parameters.

I've read more on rectypes and it's certainly n= ot to be used lightly!


On Sat, Sep 10, 2011 at 12:54 AM, Philippe Veber <philippe.veber@gmail.com<= /a>> wrote:
You may not need the -rectypes option if yo= u add a thin layer around your functions:

=A0=A0=A0=A0=A0=A0=A0 Obj= ective Caml version 3.12.1

Findlib has been successfully loaded. Additional dir= ectives:
[...]
# type t =3D F of = (unit -> t);;
type t =3D F of (unit -> t= )
# let rec a =3D F (fun ()= -> print_endline "a" ; b)
=A0 an= d=A0=A0=A0=A0 b =3D F (fun () -> print_endline "b" ; a);;
val a : t =3D F <fun&g= t;
val b : t =3D F <fun>
# let ( ! ) (F f) =3D f (= );;
val ( ! ) : t -> t =3D <fun>
# let x1 =3D ! a;;=
a
val x1 : t =3D F <fun&= gt;
# ! x1;;
b
- : t =3D F <fun>

It works in this version because you're defining a brand new type, = and not using a type alias (like in type t =3D unit -> t). I think a rec= ord would work too, but I think either is needed to avoid using -rectypes.<= br>
cheers,
=A0 Philippe.




2011/9/10 Anthony = Tavener <anthony.tavener@gmail.com>
Thanks Jonathan! I've seen -rectypes mentioned over the years and alway= s glossed over it thinking "Ah, I'll never need that!" :P
Understandable that it's a good default to have disable= d. I'll experiment first and if I like the results I'll try to limi= t compiling with -rectypes to the smallest bit of code using it.


On Fri, Sep 9, 2011 at 5= :31 PM, Jonathan Protzenko <jonathan.protzenko@gmail.com>= ; wrote:
You can use equirecursive types, which can be enabled through the -rectypes= command-line switch. With that option, your example above type-checks. How= ever, these are not enabled by default for a variety of reasons, the most i= mportant 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 cod= e, essentially representing current UI mode by one of these closures. But t= hen I run into a problem because the types are infinite (returns a function= , which returns a function, ...)

A simplified example:

# let rec a () =3D printf "state a\n"; b
=A0 =A0 =A0 and b () =3D printf "state b\n"; a

Error: This expression has type unit -> unit -> 'a
=A0 =A0 =A0 but an expression was expected of type 'a


Is there a way I can do this? To express (or 'hide') the cyclic nat= ure of the type resolution?

I've considered using continuations, but that seems heavy-weight for wh= at 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 aro= und -- but for a task worthy of it!).

I can use a variant to represent states/modes and have a dispatcher which r= uns the right code... but this introduces what feels like an unnecessary la= yer of distraction. Returning the closure of the "next state" see= ms straightforward, but introduces cycles into the typing. :(

I'm hoping I'm missing something simple. Thank-you for any assistan= ce!

=A0-Tony




--00151747583e189bc904ac93d2b5--