Unusual type declaration and Sexplib

Unusual type declaration and Sexplib

[Dario Teixeira]

Hi,

I'm having some trouble serialising via Sexplib a data structure defined
recursively.  Consider module M defined below; note how type foobar_t includes
a "with sexp" declaration, telling the Sexplib syntax extension to create
(de)serialisers automatically.  However, type t cannot rely on that automatism,
because type declarations with the "as" operator are not fully supported.
Therefore, I need to create the (de)serialisers for this type manually.


module M:
sig
        type 'a foobar_t =
                [ `Foo of int
                | `Bar of 'a list
                ] with sexp

        type t = private [< 'a foobar_t ] as 'a

        val foo: int -> t
        val bar: t list -> t
end =
struct
        type 'a foobar_t =
                [ `Foo of int
                | `Bar of 'a list
                ] with sexp

        type t = 'a foobar_t as 'a

        let foo x = `Foo x
        let bar x = `Bar x
end


So basically the problem is creating the functions with the following signatures:

val sexp_of_t: t -> Sexplib.Sexp.t
val t_of_sexp: Sexplib.Sexp.t -> t

Using as base the automatically created functions whose signatures are as follows:

val sexp_of_foobar_t: ('a -> Sexplib.Sexp.t) -> 'a foobar_t -> Sexplib.Sexp.t
val foobar_t_of_sexp: (Sexplib.Sexp.t -> 'a) -> Sexplib.Sexp.t -> 'a foobar_t

But in practice, I'm having trouble seeing how these later functions can
be used.  The problem lies in their recursive definition: how would I
break it?  (And yes, I realise that the definition of type t is unusual,
but it's extremely convenient for avoiding a lot of explicit annotations
and coercions [1]).

Thanks for your help!
Best regards,
Dario Teixeira

[1] http://groups.google.com/group/fa.caml/browse_thread/thread/7552095ab859fb5f/9c4a6fd19812fbcc

Re: [Caml-list] Unusual type declaration and Sexplib

[Jacques Garrigue]

From: Dario Teixeira <darioteixeira@yahoo.com>

> I'm having some trouble serialising via Sexplib a data structure defined
> recursively.  Consider module M defined below; note how type foobar_t includes
> a "with sexp" declaration, telling the Sexplib syntax extension to create
> (de)serialisers automatically.  However, type t cannot rely on that automatism,
> because type declarations with the "as" operator are not fully supported.
> Therefore, I need to create the (de)serialisers for this type manually.

You program below is exactly equivalent to the following, without as.
Or si your real code something different?

module M:
sig
        type 'a foobar_t =
                [ `Foo of int
                | `Bar of 'a list ]

        type t = private [< t foobar_t ]

        val foo: int -> t
        val bar: t list -> t
end =
struct
        type 'a foobar_t =
                [ `Foo of int
                | `Bar of 'a list ]

        type t = t foobar_t

        let foo x = `Foo x
        let bar x = `Bar x
end

Jacques Garrigue

> module M:
> sig
>         type 'a foobar_t =
>                 [ `Foo of int
>                 | `Bar of 'a list
>                 ] with sexp
> 
>         type t = private [< 'a foobar_t ] as 'a
> 
>         val foo: int -> t
>         val bar: t list -> t
> end =
> struct
>         type 'a foobar_t =
>                 [ `Foo of int
>                 | `Bar of 'a list
>                 ] with sexp
> 
>         type t = 'a foobar_t as 'a
> 
>         let foo x = `Foo x
>         let bar x = `Bar x
> end

Re: [Caml-list] Unusual type declaration and Sexplib

[Dario Teixeira]

Hi,

> You program below is exactly equivalent to the following,
> without as. Or is your real code something different?

You're right, the formulation without 'as' is simpler, and Sexplib handles
it just fine.  The real code adds a phantom type variable to t, and the
advantage of using 'as' was making the phantomness obvious:

type +'a t = private [< 'b node_t ] as 'b

versus

type +'a t = private [< 'a t node_t ]

But in this case, 'as' does raise more trouble than it's worth...
Anyway, issue solved -- thanks!

Best regards,
Dario Teixeira