From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader02.eternal-september.org!aioe.org!5WHqCw2XxjHb2npjM9GYbw.user.gioia.aioe.org.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Lower bounds of Strings Date: Wed, 6 Jan 2021 10:13:06 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <1cc09f04-98f2-4ef3-ac84-9a9ca5aa3fd5n@googlegroups.com> NNTP-Posting-Host: 5WHqCw2XxjHb2npjM9GYbw.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 X-Notice: Filtered by postfilter v. 0.9.2 Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:61050 List-Id: On 2021-01-06 04:08, Randy Brukardt wrote: > IMHO, "String" shouldn't be an array at all. In a UTF-8 world, it makes > little sense to index into a string - it would be expensive to do it based > on characters (since they vary in size), and dangerous to do it based on > octets (since you could get part of a character). It will not work. There is no useful integral operations defined on strings. It is like arguing that image is not an array of pixels because you could distort objects in there when altering individual pixels. > The only real solution is to never use String in the first place. A number > of people are building UTF-8 abstractions to replace String, and I expect > those to become common in the coming years. This will never happen. Ada standard library already has lots of integral operations defined on strings. They are practically never used. The UTF-8 (or whatever encoding) abstraction thing simply does not exist. > Indeed, (as I've mentioned before) I would go further and abandon arrays > altogether -- containers cover the same ground (or could easily) -- the vast > complication of operators popping up much after type declarations, > assignable slices, and supernull arrays all waste resources and cause > oddities and dangers. It's a waste of time to fix arrays in Ada -- just > don't use them. How these containers are supposed to be implemented? As linked lists? How Stream_Element_Array is supposed to be an opaque container? How file read operation is supposed to assign part of a container? You cannot rid of array interface with all its types involved: index, index set (range), element, element set (array). A containers without the array interface cannot replace array. Any language must support them. The problem is that Ada has array interfaces once built-in and as an ugly lame monstrosity of helper tagged types, a mockery of array. Array implementation is a fundamental building block of computing. That does not go either. Of course you could have two languages, one with arrays to implement containers and one without them for end users. But this is neither Ada philosophy nor a concept for any good universal-purpose language. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de