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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 575C57F02D for ; Mon, 6 Oct 2014 10:15:09 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=pra; client-ip=193.252.23.211; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=mailfrom; client-ip=193.252.23.211; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@msa.smtpout.orange.fr) identity=helo; client-ip=193.252.23.211; receiver=mail2-smtp-roc.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: ApEBAClOMlTB/BfTm2dsb2JhbABfDoctzUGDIQKBGgERAQEBAQEICQsJFCyEBAEBBCMVQAEQCxgCAgUWCwICCQMCAQIBRQYBDAEHAQGIPqsilCUBF4EsjxkHgneBVAEEnT6BLYYxO49RIIEZQoM0AQEB X-IPAS-Result: ApEBAClOMlTB/BfTm2dsb2JhbABfDoctzUGDIQKBGgERAQEBAQEICQsJFCyEBAEBBCMVQAEQCxgCAgUWCwICCQMCAQIBRQYBDAEHAQGIPqsilCUBF4EsjxkHgneBVAEEnT6BLYYxO49RIIEZQoM0AQEB X-IronPort-AV: E=Sophos;i="5.04,662,1406584800"; d="scan'208";a="99550488" Received: from msa02.smtpout.orange.fr (HELO msa.smtpout.orange.fr) ([193.252.23.211]) by mail2-smtp-roc.national.inria.fr with ESMTP; 06 Oct 2014 10:15:08 +0200 Received: from [192.168.1.132] ([92.151.28.194]) by mwinf5d58 with ME id zkF61o0074BH61003kF6a1; Mon, 06 Oct 2014 10:15:08 +0200 X-ME-Helo: [192.168.1.132] X-ME-Auth: bGV4aWZpQHdhbmFkb28uZnI= X-ME-Date: Mon, 06 Oct 2014 10:15:08 +0200 X-ME-IP: 92.151.28.194 Message-ID: <54324F8A.4070004@frisch.fr> Date: Mon, 06 Oct 2014 10:15:06 +0200 From: Alain Frisch User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Jacques Garrigue , Gabriel Scherer CC: OCaML List Mailing References: <8BB0EB51-3516-4CB9-94EC-513BA87CD4FF@math.nagoya-u.ac.jp> In-Reply-To: <8BB0EB51-3516-4CB9-94EC-513BA87CD4FF@math.nagoya-u.ac.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] Feedback on -safe-string migration attempts On 10/06/2014 04:11 AM, Jacques Garrigue wrote: > Actually, I think no decision was reached whether the ability to have > different internal representations for string and bytes is really important. > This may matter when you use javascript as backend, but otherwise? I think it's good to keep the freedom to change the representation of immutable text. This could simplify some migration path towards Unicode and/or allow using more clever representations (such as ropes, strings with lazy concatenation, etc). Generally speaking, I agree with Gabriel that the distinction between strings and bytes is more about "text" vs "compact byte array" data, than between immutable vs mutable. I'm not sure about the need to track immutability (or read-only permission) on "byte array", though. Why would this be more important than on other kind of arrays? In particular, for numerical code, it would be equally useful to specify immutability of vectors/matrices. Do we want to go into this direction of tracking mutation of arrays? Actually, I think it would be interesting to introduce a module type "ARRAY" for arrays with a fixed type "elt" of elements, add a Make functor to the Array module, and arrange so that "Bytes" is a subtype of "ARRAY with type elt = char" (in particular, it's "t" type shouldn't be more parametric than the one in the ARRAY signature). We could similarly provide a compact "BoolArray" implementation, and if we ever decide to drop the automatic runtime unboxing of float arrays, we would of course provide a "FloatArray" replacement. "Polymorphic" algorithms on arrays could be parametrized by a first-class ARRAY module argument (and this would possibly work nicely with modular implicits, and possibly with a more aggressive inliner). This is quite independent from the current discussion, but perhaps it shows that we shouldn't treat "Bytes" too specifically compared to other kinds of arrays. Alain