From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,40843b637af826a
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.180.81.40 with SMTP id w8mr3429523wix.0.1354124104426;
        Wed, 28 Nov 2012 09:35:04 -0800 (PST)
Path: 
 q13ni67343wii.0!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!87.79.20.101.MISMATCH!newsreader4.netcologne.de!news.netcologne.de!newsfeed.straub-nv.de!uucp.gnuu.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Wed, 28 Nov 2012 18:35:06 +0100
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: IBM 437 encoded String to UTF-16 Wide_String
References: <11112110-03b1-4977-ba80-00204926ea23@googlegroups.com>
 <68663891-14ad-4780-a00d-1cc48ed75323@googlegroups.com>
 <027679a1-dc5e-4888-9dd1-2a4ccf32e66c@googlegroups.com>
 <mv2j5fu41fb6.rc23cjp3s2bs$.dlg@40tude.net>
 <50b5dcd0$0$6581$9b4e6d93@newsspool3.arcor-online.net>
 <1mefvxxar8vn3$.16pejjtgf8hhg.dlg@40tude.net>
 <50b5f60e$0$9524$9b4e6d93@newsspool1.arcor-online.net>
 <347rnekt4in1.12pbyz0phdelf$.dlg@40tude.net>
 <50b615d5$0$6584$9b4e6d93@newsspool3.arcor-online.net>
 <11j81z9v2gr02$.kxnnq6lqzoz$.dlg@40tude.net>
In-Reply-To: <11j81z9v2gr02$.kxnnq6lqzoz$.dlg@40tude.net>
X-Enigmail-Version: 1.4.6
Message-ID: <50b64b47$0$6571$9b4e6d93@newsspool3.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 28 Nov 2012 18:35:03 CET
NNTP-Posting-Host: 879c14fe.newsspool3.arcor-online.net
X-Trace: 
 DXC=lE7`5_JZ0@of1oJaJ0@dmgMcF=Q^Z^V3h4Fo<]lROoRa8kF<OcfhCOkLSZBP=Ik7^onc\616M64>jLh>_cHTX3jm64gd:@aM11c
X-Complaints-To: usenet-abuse@arcor.de
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Date: 2012-11-28T18:35:03+01:00
List-Id: <comp.lang.ada>

On 28.11.12 15:23, Dmitry A. Kazakov wrote:
> On Wed, 28 Nov 2012 14:47:10 +0100, Georg Bauhaus wrote:
> 
>> On 28.11.12 14:36, Dmitry A. Kazakov wrote:
>>> The problem is not construction of a container
>>> type. It is the relation of the obtained type to the string interface. The
>>> string interface is an array of code points. The container must implement
>>> this interface in order to be a string. All strings must implement this
>>> interface, this is why they are called "strings."
>>
>> This says that a string interface consists of operations
>> that allow us to use string objects like one uses arrays.
> 
> It say that instance implementing the interface are substitutable where a
> string is expected. You should be able to pass IBM_437_String to Put_Line,
> Trim, To_Lower etc.
> 
>> Is this set of array ops not included in a Vector's interface,
> 
> By which means the language or the reader knows if it is?

This is why I mentioned generics. It is not nice, but lets the
reader see the expected interface:

   generic
      type Apple is (<>);

      with package V is
        new Ada.Containers.Vectors (Element_Type => Apple,
                                    others => <>);
   package String_Ops is

      type String is new V.Vector with null record;

      Pattern_Error : exception;

      procedure Put_Line (Source : String);  -- not normally here

      function Slice (Source : String;
                      Low    : V.Index_Type;
                      High   : V.Extended_Index) return String;

      function Index (Source, Pattern : String) return V.Extended_Index;

   end String_Ops;

Or even

   generic
      type Element_Type is ...
   package Ada.Containers.Strings is ...

I don't prefer these types of generics to an improved type system,
one that is less complex and less full of historical reasons.
But since Ada is not going to get this sort of type system...

> Ada had manifesting type system, so far...
> 
>> Which algorithms require a String_Interface that excludes
>> other array/vector operations?
> 
> ?

That is, is there a set difference between string operations
and "vector" operations such that, from a user's perspective,
nothing could turn vectors into objects of type String, or
Wide_String, or Wide_Wide_String?