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 28FEA7F9D6 for ; Fri, 4 Jul 2014 22:39:07 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of mmatalka@gmail.com) identity=pra; client-ip=74.125.82.170; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="mmatalka@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of mmatalka@gmail.com designates 74.125.82.170 as permitted sender) identity=mailfrom; client-ip=74.125.82.170; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="mmatalka@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-we0-f170.google.com) identity=helo; client-ip=74.125.82.170; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="postmaster@mail-we0-f170.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEHALwQt1NKfVKqlGdsb2JhbAAgOoJqdk2uSJAxhz8BgQsWDwEBAQEHCwsJEiqEAwEBAQMBEi4BFAcSCwEDAQsGBQsNCQQhDwEEDQIRAQUBChgTCQkCBweICwEDCQgBBAijMWqNGYMQjmUKGScDCmSFbhEBBQ6MbAqCHgeCNg9EgToFhGkFlAgDgX2BSIwwhCNBhHNs X-IPAS-Result: AkEHALwQt1NKfVKqlGdsb2JhbAAgOoJqdk2uSJAxhz8BgQsWDwEBAQEHCwsJEiqEAwEBAQMBEi4BFAcSCwEDAQsGBQsNCQQhDwEEDQIRAQUBChgTCQkCBweICwEDCQgBBAijMWqNGYMQjmUKGScDCmSFbhEBBQ6MbAqCHgeCNg9EgToFhGkFlAgDgX2BSIwwhCNBhHNs X-IronPort-AV: E=Sophos;i="5.01,603,1400018400"; d="scan'208";a="70197445" Received: from mail-we0-f170.google.com ([74.125.82.170]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 04 Jul 2014 22:39:03 +0200 Received: by mail-we0-f170.google.com with SMTP id w61so2089616wes.15 for ; Fri, 04 Jul 2014 13:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=jwPwt4w2nDKFh16yUydrQgo9vfHk67FjC9yiPqunlck=; b=CvH+3RvoIg9Egv0doNANHjTo+nQWP8G1tSqlX9kSQS11pc8eHQclzRKfnJzxdzlABJ cBd21tV3Sn3k/4CLKHVTNlYRfoOUY57Dj+OE1dtPUkDrwAH+4E3FNAWPDth2qoDnhBXX qwg1eo7slv9BqguEaCgK1cM72UsgtaKlxKO+JsXhBU26UFobWBf/UupXnXSZRZZ2Lmz8 3a9X23K4oDyezoATjlhCA/FrliZIzTi1UoZLj/DgOnjAsHEm4I8aAbXMKbASZOIA8QuF x4aHb3oqvF5SbAevoy97SVosz0UeP8rg4FKP1gnUe4uvg+UfH5HfuqkvheV0qtLLAe6N 6PKw== X-Received: by 10.180.101.39 with SMTP id fd7mr19845465wib.65.1404506340340; Fri, 04 Jul 2014 13:39:00 -0700 (PDT) Received: from localhost ([2a01:7e00::f03c:91ff:fe70:2696]) by mx.google.com with ESMTPSA id do5sm82986251wib.16.2014.07.04.13.38.59 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Jul 2014 13:38:59 -0700 (PDT) From: Malcolm Matalka To: Anthony Tavener Cc: Gerd Stolpmann , caml-list References: <1404501528.4384.4.camel@e130> Date: Fri, 04 Jul 2014 20:38:58 +0000 In-Reply-To: (Anthony Tavener's message of "Fri, 4 Jul 2014 14:31:30 -0600") Message-ID: <87d2dkn9jx.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Caml-list] Immutable strings I haven't really been following this but I'm curious why a new type, rstring, was not introduced? But, as for the actual impact on the community. This seems like a question the OPAM team can answer now, right? They can compile every package with immutable strings turned on and see how many fail? That would give an idea of the impact and possibly suggest a migration path or an alternative approach. /M Anthony Tavener writes: > 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 >>