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 <[email protected]>
> 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 <
> [email protected]> 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
>>>
>>>
>
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
