caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Philippe Veber <philippe.veber@gmail.com>
To: Anthony Tavener <anthony.tavener@gmail.com>
Cc: Jonathan Protzenko <jonathan.protzenko@gmail.com>, caml-list@inria.fr
Subject: Re: [Caml-list] Mutually recursive closures?
Date: Sat, 10 Sep 2011 08:54:56 +0200	[thread overview]
Message-ID: <CAOOOohRqX6VgrhA31CKvJtx1Vr6FmTSerD-US2j-HbGC-FgwGA@mail.gmail.com> (raw)
In-Reply-To: <CAN=ouMR5nav_OS+Qam7UR5=qFC7Fdvn3jeGcJPEKM0F8rv1yxQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2926 bytes --]

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 <fun>
val b : t = F <fun>
# let ( ! ) (F f) = f ();;
val ( ! ) : t -> t = <fun>
# let x1 = ! a;;
a
val x1 : t = F <fun>
# ! x1;;
b
- : t = 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 = 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 <anthony.tavener@gmail.com>

> 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
>>>
>>>
>

[-- Attachment #2: Type: text/html, Size: 5875 bytes --]

  reply	other threads:[~2011-09-10  6:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-09 23:14 Anthony Tavener
2011-09-09 23:31 ` Jonathan Protzenko
2011-09-10  0:47   ` Anthony Tavener
2011-09-10  6:54     ` Philippe Veber [this message]
2011-09-10 10:33       ` Anthony Tavener

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOOOohRqX6VgrhA31CKvJtx1Vr6FmTSerD-US2j-HbGC-FgwGA@mail.gmail.com \
    --to=philippe.veber@gmail.com \
    --cc=anthony.tavener@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=jonathan.protzenko@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).