From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id C7FF97EFCD for ; Wed, 1 Oct 2014 14:00:38 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=pra; client-ip=212.227.17.10; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=mailfrom; client-ip=212.227.17.10; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.kundenserver.de) identity=helo; client-ip=212.227.17.10; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="postmaster@mout.kundenserver.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0BABjsK1TU4xEKnGdsb2JhbABggyM+WY5Cu3aHUQKBCRYBEQEBAQEBBg0JCRQshAQBAQQnLiQQCy0ZVxkJiDkJqDMhbw2UQgEXihWDfoFtJgcKDIQ1BYYqi3+EAI5dBZIAagGCSQEBAQ X-IPAS-Result: Aq0BABjsK1TU4xEKnGdsb2JhbABggyM+WY5Cu3aHUQKBCRYBEQEBAQEBBg0JCRQshAQBAQQnLiQQCy0ZVxkJiDkJqDMhbw2UQgEXihWDfoFtJgcKDIQ1BYYqi3+EAI5dBZIAagGCSQEBAQ X-IronPort-AV: E=Sophos;i="5.04,632,1406584800"; d="asc'?scan'208";a="81526334" Received: from mout.kundenserver.de ([212.227.17.10]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Oct 2014 14:00:37 +0200 Received: from office1.lan.sumadev.de (dslb-178-004-068-137.178.004.pools.vodafone-ip.de [178.4.68.137]) by mrelayeu.kundenserver.de (node=mreue101) with ESMTP (Nemesis) id 0Lcxai-1XzWa30XwG-00iFu4; Wed, 01 Oct 2014 14:00:35 +0200 Received: from [192.168.10.100] (unknown [5.146.48.81]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id D32C9DC270; Wed, 1 Oct 2014 14:00:33 +0200 (CEST) Message-ID: <1412164827.5797.143.camel@e130> From: Gerd Stolpmann To: oleg@okmij.org Cc: gabriel.scherer@gmail.com, goswin-v-b@web.de, caml-list@inria.fr Date: Wed, 01 Oct 2014 14:00:27 +0200 In-Reply-To: <20141001102943.AA0C0C382A@www1.g3.pair.com> References: <20141001102943.AA0C0C382A@www1.g3.pair.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-LsxHaeGBLL31omD6GcyH" X-Mailer: Evolution 3.10.4-0ubuntu1 Mime-Version: 1.0 X-Provags-ID: V02:K0:w4akztb0NdCIKse0e1mx2gv7P+lNZMlgjjNfoCkDJQR WaGzpiJ9PMpwqT2IAko51d+VYmEncLWmPHa19XIHgz/80wlgoC P31OG52LsIkTkwW32ctSN7TDpymfHaVDBVdZOC+LdOGlgiEh7q YsieIhyvSQVqWyCDvi8ZMcQZju3IEAUcOeNU+MmAnkhhUTdBEj i8T+1b7hAb4sXA/+1WtRK4lUttRzVUy8L0HDNUMtsUS/FV5VwG pHdZmwRkqPS4ioM6tdMGjnXuxDXrk/tHJ0PhUl3xZvmzsZKy1x mpJ4bscReah+BJQjKiQXbVG6JqhjtCigYJioL77AzKQGLHhOzy nhl8Eelzfh/t6Fygs0VB8li7n9pwFlZDzDcy4CgX7 X-UI-Out-Filterresults: notjunk:1; Subject: Re: [Caml-list] Why List.map does not be implemented --=-LsxHaeGBLL31omD6GcyH Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Am Mittwoch, den 01.10.2014, 06:29 -0400 schrieb oleg@okmij.org: > To understand the problem, let us recall the main principle stated > earlier: ``There are two ways the function call (flip 0.5) > can return: it can return with true or with false.'' That is, the > function call (flip 0.5) returns *twice*. Therefore, the call (f h) > in the let cell statement returns twice. Therefore, the assignment > dst.tl <- Obj.magic cell; > will be executed twice. And the second execution of that assignment > will be with a different cell, which will override and destroy the > result of the first assignment. That is how the "true" choices became > lost. IMHO this is irrelevant for the normal OCaml evaluation regime. The standard interpretation of a type 'a -> 'b is that it returns only once. There is no alternate local world. I don't know what Hansei is doing to get this effect, but it looks like it uses continuations, STM, or some other technique to checkpoint some state and restart from there. This technique is obviously not taking local state into account (which would also have to be duplicated), but this is a limitation of this technique. I don't think this is a valid argument against using hidden local state. It's more an argument that if you use such checkpointing techniques, you need to be extremely careful. Gerd >=20 >=20 >=20 --=20 ------------------------------------------------------------ Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de My OCaml site: http://www.camlcity.org Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de ------------------------------------------------------------ --=-LsxHaeGBLL31omD6GcyH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJUK+zbAAoJEAaM4b9ZLB5TjIIH/3Iq7hNhJabNhEgKJF6+4xL8 D2Q6gWvT8VlNqOs95sgJcTgxE8VN5WxM1Tc6dEnCE3ItH/tANOzgvqcy/aYHjTeT hMSiLS8wkxwQdDm8w4a1SZ9hf4VkFe/z6sy5xI7G5Fv/Ec1zE77oyhhtr5nDv6jr Y2mHXksuMD2oP4jx6MAOcvLvXdGOIcvEH3uLLzvgrZQNH+RAv+3z1yae46tuDAfK C+yFRwUqep6zem+ud0Tlh/IjaugRurutSkhLR4siE3IMlp56l029swOiQCFaiWWB w6qcMq9EIT1x/1XPhOtXYOf6OlGhzv2IMnpZt4xKbnT0oz6OAxqt/d2lsOdg6v8= =0aaW -----END PGP SIGNATURE----- --=-LsxHaeGBLL31omD6GcyH--