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.
next prev parent 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