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

Re: [Caml-list] type of ==

[Remi Vanicat]

On 4/18/05, Jon Harrop <jon@ffconsultancy.com> wrote:
> On Monday 18 April 2005 10:18, Christophe DEHLINGER wrote:
> > 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 ?
> 
> If there were an "'a -> 'b -> bool" physical equality test, how could it ever
> return "true"?

Well, when I wrote my Weak memo module (see
http://aspellfr.free.fr/hweak/doc/Weak_memo.html), I add the need too
compare two object having a different type (too know if they are
actually the same or not). So I needed a egalyty having the type <..>
-> <..> -> bool

One could wrote one :

# let eq x y = (x : < .. > :> < > ) == (y : < .. > :> < >);;
val eq : < .. > -> < .. > -> bool = <fun>

But I don't know how to write it for polymorphic variant (without the
Obj module) for example, and someone may want to do a similar weak
memo on them (Notice that if one could write this, then one can do the
same on structural equality, and I'm not sure that one want to use
this on structural equality as I don't know what will appen if you try
to compare `Foo 10 with `Foo (10.) or some nasty things like that)

Re: [Caml-list] type of ==

[Jon Harrop]

On Monday 18 April 2005 13:11, Andreas Rossberg wrote:
> Either when 'a and 'b happen to be instantiated to the same type,

Yes, I realised this just after posting (thanks Diego!).

> or when the representation happens to be the same, e.g. 0 == false.

Assuming this is for an OCaml-only program, it sounds as though the "other" 
possible types 'a and 'b should be put into a single variant type. Then you 
can use "'a -> 'a -> bool" with "'a = your variant type". Does that make any 
sense? :-)

You'd have to indirect the physical equality once though, e.g.:

# type ('a, 'b) a = A of 'a | B of 'b;;
type ('a, 'b) a = A of 'a | B of 'b
# let compare_a x y = match x, y with
    A x, A y -> x == y
  | B x, B y -> x == y
  | _ -> false;;
val compare_a : ('a, 'b) a -> ('a, 'b) a -> bool = <fun>

A good excuse not to do this would be when you're writing a veneer between 
OCaml and C in OCaml.

> The latter also provides a good argument against making physical equality
> too polymorphic. It would break abstraction, much worse than it does
> already. In particular, a program's meaning could depend on implementation
> details (like false being represented by 0) in very questionable ways.

Yes, although this is already the case when applying "=" to abstract types 
(implementation of the type in that case, rather than of the language 
itself).

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] type of ==

[Christophe DEHLINGER]

Andreas Rossberg wrote:

>The latter also provides a good argument against making physical equality
>too polymorphic. It would break abstraction, much worse than it does
>already. In particular, a program's meaning could depend on implementation
>details (like false being represented by 0) in very questionable ways.
>  
>
It's arguable that it wouldn't be /that/ much worse than the current 
situation, where == on non-mutable structures is already implementation 
dependent.
I am not advocating for such a change though, if only because in most 
cases the arguments of == are known to be of the same type, so it is a 
good thing to be able to take advantage of this information. However, it 
would still be nice to have both equalities available (yes, I know, yet 
another equality). In the problem I'm working on, only mutable 
structures are compared, so the extended == would work as intended. Of 
course, you would have to know what you're doing when using this 
predicate, but this is already the case for the current two equalities : 
you have to watch out for the aforementioned non-mutable structures with 
== and for cyclic values with = .

Call me pessimistic, but I have little hope that this "feature wish" 
will be fulfilled, so I would happily settle for fun a b -> a == 
(Obj.magic b) (if it works, still haven't had a chance to try it). I'd 
be grateful if someone could tell me whether this particular use of 
Obj.magic is safe.

Christophe


__________________________

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
__________________________

Re: [Caml-list] type of ==

[Andreas Rossberg]

Jon Harrop <jon@ffconsultancy.com>:
>
> If there were an "'a -> 'b -> bool" physical equality test, how could it
ever
> return "true"?

Either when 'a and 'b happen to be instantiated to the same type, or when
the representation happens to be the same, e.g. 0 == false.

The latter also provides a good argument against making physical equality
too polymorphic. It would break abstraction, much worse than it does
already. In particular, a program's meaning could depend on implementation
details (like false being represented by 0) in very questionable ways.

Cheers,

  - Andreas

Re: [Caml-list] type of ==

[Jon Harrop]

On Monday 18 April 2005 10:18, Christophe DEHLINGER wrote:
> 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 ?

If there were an "'a -> 'b -> bool" physical equality test, how could it ever 
return "true"?

> 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.

Yes, if you're writing self-contained OCaml programs then you should never use 
Obj.

You may find the beginners list more appropriate for these kinds of questions, 
BTW.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists