caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: David Teller <David.Teller@univ-orleans.fr>
To: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Safe Obj.magic container ?
Date: Fri, 29 Feb 2008 09:18:09 +0100	[thread overview]
Message-ID: <1204273089.6845.7.camel@Blefuscu> (raw)
In-Reply-To: <20080229.105212.169552478.garrigue@math.nagoya-u.ac.jp>

Thanks for the clarification. Again, I only have polymorphic variants,
no functions, no floats, no lazy values, etc. 

The reason why I need to go through some Obj conversion is essentially
the same reason safe marshalling needs to go through that conversion:
storing typed information on an untyped medium (or, in this case,
polymorphically typed information on a non-polymorphically typed medium)
-- along with a type certificate. It just happens that this
less-richly-typed medium is an exception.

Cheers,
 David

P.S.:
 I have tried alternative solutions but the best I can come up with
involves something like 30% slowdown on my testsuite. Which is a bit too
much for something which is supposed to be speed-critical.

On Fri, 2008-02-29 at 10:52 +0900, Jacques Garrigue wrote:
> From: David Teller <David.Teller@univ-orleans.fr>
> 
> > Interesting. Can I assume that, if my type is boxed (in this case, a
> > polymorphic variant), I can successfully convert it to Obj.t and back ?
> 
> Yes : polymorphic variants are either ints or normal blocks, so this
> should work. This is also true for normal variants. Actually I don't
> know of any non-uniform representation problem outside of floats.
> 
> Note however that this problem of non-uniform representation is no the
> only danger when using Obj.magic imprudently. I recall another problem
> with functional values. I'm afraid only Xavier could explain that one.
> 
> If you have only (polymorphic) variants, and if you keep the types
> monomorphic (i.e. always add complete type annotations to Obj.magic or
> Obj.obj), things should work properly in the current implementation.
> 
> Of course you should limit that kind of uses to things like
> persistant storage or C interfaces, where you have to go through an
> untyped world anyway, and avoid it at all costs in plain ml programs.
> 
> Jacques Garrigue
> 
-- 
David Teller
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
 Angry researcher: French Universities need reforms, but the LRU act brings liquidations. 


  reply	other threads:[~2008-02-29  8:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-27  9:09 David Teller
2008-02-27  9:43 ` [Caml-list] " Luc Maranget
     [not found]   ` <37B36607-9F22-4537-B4DB-1E04348E2B90@inria.fr>
2008-02-28 14:23     ` Damien Doligez
2008-02-28 15:29       ` David Teller
2008-02-28 16:24         ` Damien Doligez
2008-02-29  1:52         ` Jacques Garrigue
2008-02-29  8:18           ` David Teller [this message]
2008-02-28 19:20       ` Jake Donham
2008-02-28 23:19         ` Richard Jones
2008-02-27 11:23 ` Tom Primožič
2008-02-27 21:22   ` David Teller

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=1204273089.6845.7.camel@Blefuscu \
    --to=david.teller@univ-orleans.fr \
    --cc=caml-list@inria.fr \
    --cc=garrigue@math.nagoya-u.ac.jp \
    /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;
as well as URLs for NNTP newsgroup(s).