Type_of?

Type_of?

[Dario Teixeira]

Hi,

I'm using the XHTML.M module from the Ocsigen project to generate valid
XHTML pages.  It makes heavy use of polymorphic variants, and as such the
types produced can be quite verbose and complex.  In practice, however, one
is rarely confronted with them (thank goodness for latent typing and type
inference!).  There is one exception, though: when unmarshalling, one must
explicitly provide the return type.  And this is the context for my question.

So, imagine I have a module with only two functions.  The first, "make_doc",
uses XHTML.M and its signature is therefore quite complex.  This is what
"ocamlc -i" tells me:

val make_doc: string ->
        [< `Address | `Blockquote | `Del | `Div | `Dl | `Fieldset | `Form | `H1
        | `H2 | `H3 | `H4 | `H5 | `H6 | `Hr | `Ins | `Noscript | `Ol | `P |
`PCDATA
        | `Pre | `Script | `Table | `Ul > `Blockquote `H1 `P ]
        XHTML.M.elt list


The second function, "unpickle_doc", uses the Marshal module to deserialise
from a string a previously pickled doc.  This is the definition of this
function:  (note that I've used copy & paste of the previous output of
"ocamlc -i" to provide the explicit type annotation)

let unpickle_doc str :
        [< `Address | `Blockquote | `Del | `Div | `Dl | `Fieldset | `Form | `H1
        | `H2 | `H3 | `H4 | `H5 | `H6 | `Hr | `Ins | `Noscript | `Ol | `P |
`PCDATA
        | `Pre | `Script | `Table | `Ul > `Blockquote `H1 `P ]
        XHTML.M.elt list
        = Marshal.from_string str 0


Now, this works fine.  It is however error prone, since if the signature
of make_doc changes somewhat and I forget to update the type annotation in
unpickle_doc, then I get a nasty runtime segfault.  So this is my question:
since the return type of make_doc is known at compile-time, is there any
way I can tell the compiler that the return type of unpickle_doc should be
the same as make_doc's?

Thank you for your help!
Dario Teixeira





      ___________________________________________________________
Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/

Re: [Caml-list] Type_of?

[Jeremy Yallop]

Dario Teixeira wrote:
> So, imagine I have a module with only two functions.  The first, "make_doc",
> uses XHTML.M and its signature is therefore quite complex.  This is what
> "ocamlc -i" tells me:
[...]
> The second function, "unpickle_doc", uses the Marshal module to deserialise
> from a string a previously pickled doc.  This is the definition of this
> function:  (note that I've used copy & paste of the previous output of
> "ocamlc -i" to provide the explicit type annotation)
[...]
> Now, this works fine.  It is however error prone, since if the signature
> of make_doc changes somewhat and I forget to update the type annotation in
> unpickle_doc, then I get a nasty runtime segfault.  So this is my question:
> since the return type of make_doc is known at compile-time, is there any
> way I can tell the compiler that the return type of unpickle_doc should be
> the same as make_doc's?

One way is to use both functions in a context which requires the return 
types to be the same.  For example, you could use both functions to 
create the elements of a list:

   let rec unpickle_doc str =
     let _unify_return_types _ = [unpickle_doc ""; make_doc ""] in
       Marshal.from_string str 0

Jeremy.

Re: [Caml-list] Type_of?

[Arnaud Spiwack]

Hello,

How about giving it a name ?

For instance:

type 'a make_doc_type = 'a XHTML.M.elt list
   constraint 'a =  [< `Address | `Blockquote | `Del | `Div | `Dl | 
`Fieldset | `Form | `H1 | `H2 | `H3 | `H4 | `H5 | `H6 | `Hr | `Ins | 
`Noscript | `Ol | `P | `PCDATA | `Pre | `Script | `Table | `Ul > 
`Blockquote `H1 `P ]

(this is untested, might contain a few dozens syntax errors, but it's 
the idea).



Arnaud Spiwack

Dario Teixeira a écrit :
> Hi,
>
> I'm using the XHTML.M module from the Ocsigen project to generate valid
> XHTML pages.  It makes heavy use of polymorphic variants, and as such the
> types produced can be quite verbose and complex.  In practice, however, one
> is rarely confronted with them (thank goodness for latent typing and type
> inference!).  There is one exception, though: when unmarshalling, one must
> explicitly provide the return type.  And this is the context for my question.
>
> So, imagine I have a module with only two functions.  The first, "make_doc",
> uses XHTML.M and its signature is therefore quite complex.  This is what
> "ocamlc -i" tells me:
>
> val make_doc: string ->
>         [< `Address | `Blockquote | `Del | `Div | `Dl | `Fieldset | `Form | `H1
>         | `H2 | `H3 | `H4 | `H5 | `H6 | `Hr | `Ins | `Noscript | `Ol | `P |
> `PCDATA
>         | `Pre | `Script | `Table | `Ul > `Blockquote `H1 `P ]
>         XHTML.M.elt list
>
>
> The second function, "unpickle_doc", uses the Marshal module to deserialise
> from a string a previously pickled doc.  This is the definition of this
> function:  (note that I've used copy & paste of the previous output of
> "ocamlc -i" to provide the explicit type annotation)
>
> let unpickle_doc str :
>         [< `Address | `Blockquote | `Del | `Div | `Dl | `Fieldset | `Form | `H1
>         | `H2 | `H3 | `H4 | `H5 | `H6 | `Hr | `Ins | `Noscript | `Ol | `P |
> `PCDATA
>         | `Pre | `Script | `Table | `Ul > `Blockquote `H1 `P ]
>         XHTML.M.elt list
>         = Marshal.from_string str 0
>
>
> Now, this works fine.  It is however error prone, since if the signature
> of make_doc changes somewhat and I forget to update the type annotation in
> unpickle_doc, then I get a nasty runtime segfault.  So this is my question:
> since the return type of make_doc is known at compile-time, is there any
> way I can tell the compiler that the return type of unpickle_doc should be
> the same as make_doc's?
>
> Thank you for your help!
> Dario Teixeira
>
>
>
>
>
>       ___________________________________________________________
> Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>   

Re: Type_of?

[Zheng Li]

Hello, 

Dario Teixeira <darioteixeira@yahoo.com> writes:
> Now, this works fine.  It is however error prone, since if the signature
> of make_doc changes somewhat and I forget to update the type annotation in
> unpickle_doc, then I get a nasty runtime segfault.  So this is my question:
> since the return type of make_doc is known at compile-time, is there any
> way I can tell the compiler that the return type of unpickle_doc should be
> the same as make_doc's?

Do you have any restriction in bounding them as pairs? The simplest
example come into my mind is like:

# let produce () :'a = [`Zero; `One 1] and consume (l:'a) = ();;
val produce : unit -> [> `One of int | `Zero ] list = <fun>
val consume : [> `One of int | `Zero ] list -> unit = <fun>

In this way, you don't have to write the variants manually, since
"ocamlc -i" can inference it and the type 'a in the pairs are always
bounded.

HTH.
-- 
Zheng Li
http://www.pps.jussieu.fr/~li

type of ==

[Christophe DEHLINGER]

Hi all,

I was recently in a situation where I would have liked to be able to 
test physical equality on terms of possibly different types, but 
couldn't because of =='s 'a -> 'a -> bool type.
Why isn't its type 'a -> 'b -> bool ? Is there more to the 
implementation of == than a simple physical, asm-level equality test ?
Is it because of the semantics of == ? If so, is a 'a -> 'b -> bool 
equivalent possible / already existing ? I guess something like fun a b 
-> a == (Obj.magic b) should work, but regular posts on this list have 
gradually scared me off from ever using the obscure Obj module.

Christophe Dehlinger

__________________________

Ce message (et toutes ses pièces jointes éventuelles) est confidentiel et établi à l'intention exclusive de ses destinataires. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'IFP décline toute responsabilité au titre de ce message.

This message and any attachments (the message) are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. IFP should not be liable for this message.

Visitez notre site Web / Visit our web site : http://www.ifp.fr
__________________________