From: Anthony Tavener <anthony.tavener@gmail.com>
To: Jonathan Protzenko <jonathan.protzenko@gmail.com>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Mutually recursive closures?
Date: Fri, 9 Sep 2011 18:47:01 -0600 [thread overview]
Message-ID: <CAN=ouMR5nav_OS+Qam7UR5=qFC7Fdvn3jeGcJPEKM0F8rv1yxQ@mail.gmail.com> (raw)
In-Reply-To: <4E6AA1E1.9050307@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2056 bytes --]
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: 2689 bytes --]
next prev parent reply other threads:[~2011-09-10 0:47 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 [this message]
2011-09-10 6:54 ` Philippe Veber
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='CAN=ouMR5nav_OS+Qam7UR5=qFC7Fdvn3jeGcJPEKM0F8rv1yxQ@mail.gmail.com' \
--to=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