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 BE8737FA13 for ; Tue, 8 Jul 2014 15:23:08 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of garrigue@math.nagoya-u.ac.jp) identity=pra; client-ip=133.6.130.5; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="garrigue@math.nagoya-u.ac.jp"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of garrigue@math.nagoya-u.ac.jp) identity=mailfrom; client-ip=133.6.130.5; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="garrigue@math.nagoya-u.ac.jp"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mailhost.math.nagoya-u.ac.jp) identity=helo; client-ip=133.6.130.5; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="postmaster@mailhost.math.nagoya-u.ac.jp"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At0CAMzvu1OFBoIFY2dsb2JhbABQCYcpw1MBgSsEGBUGPoQDAQEFIwQZAwE1AQEOCQIOCgICGA4CAlcGLogmk0mbMHeFCAKPB4UmEAEGgSyNGygzB4J3NoEWilSQJ5de X-IPAS-Result: At0CAMzvu1OFBoIFY2dsb2JhbABQCYcpw1MBgSsEGBUGPoQDAQEFIwQZAwE1AQEOCQIOCgICGA4CAlcGLogmk0mbMHeFCAKPB4UmEAEGgSyNGygzB4J3NoEWilSQJ5de X-IronPort-AV: E=Sophos;i="5.01,625,1400018400"; d="scan'208";a="70556358" Received: from rabbit.math.nagoya-u.ac.jp (HELO mailhost.math.nagoya-u.ac.jp) ([133.6.130.5]) by mail3-smtp-sop.national.inria.fr with ESMTP; 08 Jul 2014 15:23:06 +0200 Received: from mailhost.math.nagoya-u.ac.jp (localhost [127.0.0.1]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id 1EA7363AF; Tue, 8 Jul 2014 22:23:03 +0900 (JST) Received: from mailhost.math.nagoya-u.ac.jp (localhost [127.0.0.1]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id CB2334145; Tue, 8 Jul 2014 22:23:02 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=math.nagoya-u.ac.jp; h= subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=alpha; bh=2v//1DO+KHRLDW5fJLizWjVAcWk=; b=jteFpGDXXtgw/4Nwj0D3Zh6zDNPw Qdn0w0DIilAmOA6KdpNZ6XuJw3ctoSafaz5CedT6AkxEhFMepvd/4kWfEuYEYjMa 18S7vIdDrzIUgk6mKcmtLqpolPrMibL9q7tf+92BYQ0v03KOJI+gIgBwVTfe0C5i BS53FDoBmc8rjmk= DomainKey-Signature: a=rsa-sha1; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=Y/T6zbzh+yXBNfSZrDJqfKSViDcvR5GgUrT0gdPHyXR01QTO7SIOwLwX9Qvebkm8cBTTPVFoBP/iVPm3jEu35vQ+OiBMS4CoJpGLGeNZu4X1FcaGe/9V+oAbscsoz/Wth2I8IyjYDRCbh4h9pCwUS8DQlihO9YHVPo6qm845yHE=; c=nofws; d=math.nagoya-u.ac.jp; q=dns; s=alpha Received: from tet.garrigue.jp (58x158x128x157.ap58.ftth.ucom.ne.jp [58.158.128.157]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTPSA id 56C564142; Tue, 8 Jul 2014 22:23:02 +0900 (JST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=utf-8 From: Jacques Garrigue In-Reply-To: <1404559455.4384.32.camel@e130> Date: Tue, 8 Jul 2014 22:23:01 +0900 Cc: OCaML List Mailing Content-Transfer-Encoding: quoted-printable Message-Id: References: <1404501528.4384.4.camel@e130> <1404559455.4384.32.camel@e130> To: Gerd Stolpmann X-Mailer: Apple Mail (2.1878.6) Subject: Re: [Caml-list] Immutable strings On 2014/07/05 20:24, Gerd Stolpmann wrote: >=20 > Am Freitag, den 04.07.2014, 17:01 -0400 schrieb Markus Mottl: >> I agree that the new concept has some noteworthy downsides as >> demonstrated in the Lexing-example. Your proposed solution 2 >> (stringlike) would probably solve these issues from a safety point of >> view. The downside is that the complexity of string-handling would >> increase even more, because then we would have three types to deal >> with. I personally prefer safety over convenience, but other people's >> (especially beginner's) mileage may vary. >=20 > Well, the complexity can be reduced a bit by using phantom types: >=20 > type string =3D [`String] stringlike > type bytes =3D [`Bytes] stringlike >=20 > and then just define function-by-function what is permitted: >=20 > val get : 'a stringlike -> int -> char > val set : [`Bytes] stringlike -> int -> char -> unit > val sub : 'a stringlike -> int -> int -> [`String] stringlike > val sub_bytes : 'a stringlike -> int -> int -> [`Bytes] stringlike >=20 > etc., and the modules String and Bytes would just contain aliases of > these functions with monomorphed typing. >=20 > I don't know, though, whether we can be safe to never see the > polymorphic typing when just using string and bytes. It would be a bit > surprising for beginners to see that, and you sometimes would have to > deal with unresolved type variables. Indeed. Originally the plan was to use the above scheme for strings, and use polymorphism to allow more flexibility. However, this is not 100% compatible, even if we allow to ignore the parameters, because of these unresolved type variables. This also becomes complicated when you want to take functions as parameters. The stringlike type itself is a good idea. In the standard library, it could be implemented as: type string =3D private stringlike type bytes =3D private stringlike However, it is only about allowing passing string and bytes arguments to functions in an homogeneous way. For the return case, the situation is more confused, because returning a stringlike is actually weaker than either bytes or string. Alain=E2=80=99s idea of using an extra type-only parameter (=E2=80=98a is_a= _type) works, and it doesn=E2=80=99t really need to be a GADT. But this is a bit strange to use an extra parameter where a phantom type on string itself would solve the problem. I.e., using your above approach one can be safe just writing: val copy : =E2=80=98a stringlike -> =E2=80=98b stringlike val sub : =E2=80=98a stringlike -> int -> int -> =E2=80=98b stringlike (assuming that we are always copying in sub too) One could try to mix the two approaches: i.e. have a type =E2=80=98a string= like, with explicit coercions to and from bytes and string. Note that you can do that yourself: create your own Stringlike module, with the coercions type =E2=80=99a stringlike external from_string : string -> [> `String] stringlike =3D =E2=80=9C%id= entity" external to_string : [`String] stringlike -> string =3D =E2=80=9C%identi= ty=E2=80=9D =E2=80=A6 Note that you should not write =E2=80=9Ctype +=E2=80=99a stringlike=E2=80= =9D, since you want to exploit the fact any stringlike must be monomorphic. This could of course be added to the standard library, but for compatibility reasons I think that string itself has to stay as an abstract (or private) = type with no parameter. And the above kind of coercions is compiled away, so if your goal is performance this should not be a problem. Jacques=