caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Anthony Tavener <anthony.tavener@gmail.com>
To: Philippe Veber <philippe.veber@gmail.com>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Mutually recursive closures?
Date: Sat, 10 Sep 2011 04:33:11 -0600	[thread overview]
Message-ID: <CAN=ouMR+QLebY4+k+xG8CrcXsgjdAPdspwuraKBW2p-X8+UO2Q@mail.gmail.com> (raw)
In-Reply-To: <CAOOOohRqX6VgrhA31CKvJtx1Vr6FmTSerD-US2j-HbGC-FgwGA@mail.gmail.com>

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

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
<philippe.veber@gmail.com>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 <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: 6601 bytes --]

      reply	other threads:[~2011-09-10 10:33 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
2011-09-10 10:33       ` Anthony Tavener [this message]

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='CAN=ouMR+QLebY4+k+xG8CrcXsgjdAPdspwuraKBW2p-X8+UO2Q@mail.gmail.com' \
    --to=anthony.tavener@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=philippe.veber@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).