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 92CDE7F9D5 for ; Fri, 4 Jul 2014 22:31:32 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of anthony.tavener@gmail.com) identity=pra; client-ip=209.85.128.170; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="anthony.tavener@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of anthony.tavener@gmail.com designates 209.85.128.170 as permitted sender) identity=mailfrom; client-ip=209.85.128.170; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="anthony.tavener@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ve0-f170.google.com) identity=helo; client-ip=209.85.128.170; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="postmaster@mail-ve0-f170.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooHAOQNt1PRVYCqlGdsb2JhbAAgOoNgWoJvq0yOW4FWAYc+AYEDCBYPAQEBAQcLCwkSKoQDAQEBAwESER0BFAcSCwEDAQsGAwILAxcdAgIiAREBBQEKEgYTCQkJB4gLAQMJCA2TGpAWaosngXKDEI5pChknAwpkhW4RAQUOjHaCGgQHgjYPMhIkgRYFhGkFhWOOKIF9gUiQUxgphRIeLw X-IPAS-Result: AooHAOQNt1PRVYCqlGdsb2JhbAAgOoNgWoJvq0yOW4FWAYc+AYEDCBYPAQEBAQcLCwkSKoQDAQEBAwESER0BFAcSCwEDAQsGAwILAxcdAgIiAREBBQEKEgYTCQkJB4gLAQMJCA2TGpAWaosngXKDEI5pChknAwpkhW4RAQUOjHaCGgQHgjYPMhIkgRYFhGkFhWOOKIF9gUiQUxgphRIeLw X-IronPort-AV: E=Sophos;i="5.01,603,1400018400"; d="scan'208";a="83693637" Received: from mail-ve0-f170.google.com ([209.85.128.170]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 04 Jul 2014 22:31:31 +0200 Received: by mail-ve0-f170.google.com with SMTP id i13so2038558veh.29 for ; Fri, 04 Jul 2014 13:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IMV4S0uElmakkxVpTEE6nLp6VzDUxQeaOSqW0nirCHU=; b=f3hzBTEEsuBW593RcSXeG0LTFeqezW11tAzsmUQNTEdHnP75OjMlvVnpWnTHBoOu0p se7uHdaCW34RxkqTwQRe9EwTduoZg9/0HmpJm0CGS02v4hF04891oNob6oHTHMU/lYFV E3Yylwr7M22SisUqIvnveaG9my9wV15HQgbZ2duimX5em8Uqz0AQNtb/XX+6YHjMulUQ JCCEI5a8W3F8OEIbMFEXz9LheJ548qkc3Wab9pnTcqdUKKBPWeI7m5jaI4w3yttzI68j rB6Uxm6onLd77I2C5hC8yKf2tB0G+GinwQ2P7bUIFXt7FBnDplb5qKm2oYO4fuzsCBCi 7eog== MIME-Version: 1.0 X-Received: by 10.220.81.194 with SMTP id y2mr9328159vck.29.1404505890606; Fri, 04 Jul 2014 13:31:30 -0700 (PDT) Received: by 10.220.151.12 with HTTP; Fri, 4 Jul 2014 13:31:30 -0700 (PDT) In-Reply-To: <1404501528.4384.4.camel@e130> References: <1404501528.4384.4.camel@e130> Date: Fri, 4 Jul 2014 14:31:30 -0600 Message-ID: From: Anthony Tavener To: Gerd Stolpmann Cc: caml-list Content-Type: multipart/alternative; boundary=001a11c2d860b1d25304fd640281 Subject: Re: [Caml-list] Immutable strings --001a11c2d860b1d25304fd640281 Content-Type: text/plain; charset=UTF-8 I'm rather welcoming of the immutable change (hehe) of strings, but I haven't considered these details -- perhaps because I only use strings as immutable (currently with no such guarantee!), and use bigarray for a block of mutable bytes... which is your idea #3. It seems the "bytes" type would be most useful in cases where mutable and immutable strings are used in a mixed manner... but given these practical issues you raise, it could be less pleasant than it first appears. Your "stringlike" solution seems reasonable, but I don't have a good use-case in mind for mixed mutable/immutable to help me imagine the result. What are some scenarios where this mix of types is desired? I think even Rust doesn't support mutable strings -- which seems bold for its target audience, yet they're fine with it? When I consider possible scenarios of utf8 encoded strings, and mutating that in-place... ugh. Even "back in the day", doing string operations in C on ASCII, I'd favor building a new string rather than flirting with saving ops by overwriting values in the current string. Oh! Upper/lower-case! Maybe that's the one good use-case. ;) On Fri, Jul 4, 2014 at 1:18 PM, Gerd Stolpmann wrote: > Hi list, > > I've just posted a blog article where I criticize the new concept of > immutable strings that will be available in OCaml 4.02 (as option): > > http://blog.camlcity.org/blog/bytes1.html > > In short my point is that it the new concept is not far reaching enough, > and will even have negative impact on the code quality when it is not > improved. I also present three ideas how to improve it. > > Gerd > -- > ------------------------------------------------------------ > 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 > ------------------------------------------------------------ > > > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > --001a11c2d860b1d25304fd640281 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm rather welcoming of the immutable change (heh= e) of strings, but I haven't
considered these details -- perh= aps because I only use strings as immutable
(currently with no su= ch guarantee!), and use bigarray for a block of mutable
bytes... which is your idea #3.

It seems the = "bytes" type would be most useful in cases where mutable and
immutable strings are used in a mixed manner... but given these pract= ical
issues you raise, it could be less pleasant than it first appears. You= r
"stringlike" solution seems reasonable, but I don'= ;t have a good use-case in
mind for mixed mutable/immutable to he= lp me imagine the result. What are some
scenarios where this mix of types is desired? I think even Rust doesn&= #39;t
support mutable strings -- which seems bold for its target = audience, yet
they're fine with it?

When I consider possible scenarios of utf8 encoded strings, and mutating th= at
in-place... ugh. Even "back in the day", doing strin= g operations in C on
ASCII, I'd favor building a new string r= ather than flirting with saving ops by
overwriting values in the current string. Oh! Upper/lower-case! Maybe = that's
the one good use-case. ;)



On Fri, Jul 4, = 2014 at 1:18 PM, Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
Hi list,

I've just posted a blog article where I criticize the new concept of
immutable strings that will be available in OCaml 4.02 (as option):

htt= p://blog.camlcity.org/blog/bytes1.html

In short my point is that it the new concept is not far reaching enough,
and will even have negative impact on the code quality when it is not
improved. I also present three ideas how to improve it.

Gerd
--
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany =C2=A0 =C2=A0gerd@gerd-stolpmann.de
My OCaml site: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.camlcity.org
Contact details: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.camlcity.org/contact.html
Company homepage: =C2=A0 =C2=A0 =C2=A0 http://www.gerd-stolpmann.de
------------------------------------------------------------



--
Caml-list mailing list. =C2=A0Subscription management and archives:
ht= tps://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

--001a11c2d860b1d25304fd640281--