From: rossberg@mpi-sws.org
To: oleg@okmij.org
Cc: la@iki.fi, caml-list@inria.fr
Subject: Re: [Caml-list] Re: Closure marshalling inconsistency
Date: Thu, 10 Feb 2011 11:43:15 +0100 (CET) [thread overview]
Message-ID: <0161c25695dd28a84238010d94e8166d.squirrel@mail.mpi-sws.org> (raw)
In-Reply-To: <20110210095043.E9EE817196@Adric.ern.nps.edu>
Oleg wrote:
>
> Lauri Alanko wrote:
>> Marshalling closures with references to globals is precarious
>> business.
>
> Indeed. I would not blame OCaml though: OCaml serialization functions
> (when invoked with the right flags) ensure the preservation of sharing
> of components _within_ a serialized value. There are no guarantees
> about the preservation of sharing _between_ separately serialized
> values. The documentation explicitly says so: ``Sharing between values
> marshaled by successive calls to Marshal.to_channel is not detected,
> though.'' That is, if v1 and v2 share a component, the results of
> pickling/unpickling v1 and separately v2 may not share the component.
True, but I think Lauri complains about a slightly different issue, namely
sharing inconsistencies between a _single_ marshalled value and the program
environment. Or in other words, that the language does not actually define
what it means to be "_within_ a serialized values", nor implements it
consistently.
There are obvious ways in which this could be made coherent, but they are
likely to be difficult to implement as an afterthought.
> I might agree that this is a bug -- but not that it is a bug in
> OCaml. I might agree with the argument that it is a global mutable
> variable that is the bug, in programmer's code.
He he. That sounds like an entirely un-MLish kind of argument. The language
has undefined and incoherent semantics? Of course, it's the programmer's
mistake to expect otherwise! ;)
/Andreas
prev parent reply other threads:[~2011-02-10 10:43 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-10 9:50 oleg
2011-02-10 10:43 ` rossberg [this message]
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=0161c25695dd28a84238010d94e8166d.squirrel@mail.mpi-sws.org \
--to=rossberg@mpi-sws.org \
--cc=caml-list@inria.fr \
--cc=la@iki.fi \
--cc=oleg@okmij.org \
/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