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 178587FA15 for ; Wed, 9 Jul 2014 15:54:55 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=pra; client-ip=193.252.23.212; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=mailfrom; client-ip=193.252.23.212; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@msa.smtpout.orange.fr) identity=helo; client-ip=193.252.23.212; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="postmaster@msa.smtpout.orange.fr"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucAAJVIvVPB/BfUnGdsb2JhbABZyAKDFAGBJQ8BAQEBAQgLCQkUKIQDAQEEAThAAQULCw4KCRYPCQMCAQIBRQYNAQcBARAHiB8MyGkXj0IHhEMBBJp2hw+QQg X-IPAS-Result: AucAAJVIvVPB/BfUnGdsb2JhbABZyAKDFAGBJQ8BAQEBAQgLCQkUKIQDAQEEAThAAQULCw4KCRYPCQMCAQIBRQYNAQcBARAHiB8MyGkXj0IHhEMBBJp2hw+QQg X-IronPort-AV: E=Sophos;i="5.01,631,1400018400"; d="scan'208";a="70702747" Received: from msa03.smtpout.orange.fr (HELO msa.smtpout.orange.fr) ([193.252.23.212]) by mail3-smtp-sop.national.inria.fr with ESMTP; 09 Jul 2014 15:54:54 +0200 Received: from [192.168.1.133] ([92.151.60.153]) by mwinf5d63 with ME id QDus1o00U3JNEic03Dut60; Wed, 09 Jul 2014 15:54:53 +0200 X-ME-Helo: [192.168.1.133] X-ME-Auth: bGV4aWZpQHdhbmFkb28uZnI= X-ME-Date: Wed, 09 Jul 2014 15:54:53 +0200 X-ME-IP: 92.151.60.153 Message-ID: <53BD49B1.6000203@frisch.fr> Date: Wed, 09 Jul 2014 15:54:57 +0200 From: Alain Frisch User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Gerd Stolpmann CC: caml-list References: <1404501528.4384.4.camel@e130> <53BA95AC.3050602@frisch.fr> <1404822242.4384.101.camel@e130> In-Reply-To: <1404822242.4384.101.camel@e130> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] Immutable strings On 07/08/2014 02:24 PM, Gerd Stolpmann wrote: > It will create confusion even with actively maintained code bases. What > could help here is very clear communication when the change will be the > standard behavior, and how the migration will take place. It's a very different kind of criticism from your initial point about the decision of going into the current direction. Point taken: the development team will need to communicate about the expected timeline and migrate path. But note that 4.02 is not even out, and since the default behavior is the previous one, there is no hurry, and it's fine if people wait a few months before trying the new mode. It doesn't seem crazy to wait for some early user feedback and synchronize with them before deciding on a more precise plan for the wider community. For instance, you feedback about porting ocamlnet is quite useful and the current discussion shows that several solutions compete and need further thought. Without the new compiler switch, this discussion would not have taken place. > Right, that's the good side of it. (Although the danger is quite > theoretical, as most programmers seem to intuitively follow the rule > "don't mutate strings you did not create". I've never seen this kind of > bug in practice.) Still, library functions such as string_of_bool, or string_of_format (in the previous version) had to be written carefully, with extra copies, to avoid public humiliation (or not). > I think it would be quite important to have that in the stdlib: > > - This sets a standard for interoperability between libraries > - The stdlib can exploit the details of the representation > - It would be possible to use stringlike directly in C interfaces Note that if it goes to stdlib, one cannot refer to bigarrays. (One might want to have bigarrays in stdlib, but we are not there yet.) -- Alain