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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "G.B." Newsgroups: comp.lang.ada Subject: Re: Community Input for the Maintenance and Revision of the Ada Programming Language Date: Tue, 3 Oct 2017 15:25:12 +0200 Organization: A noiseless patient Spider Message-ID: References: <915874b5-52c0-4aa8-9023-82fddedb816f@googlegroups.com> <67345f73-530c-400b-9eb4-63eeb440154c@googlegroups.com> <9a6338d9-83be-4e45-b8b7-edc56e33537f@googlegroups.com> <2deb28e2-f7e8-4461-b8b8-c2c6cf2784aa@googlegroups.com> <5de470d2-aa3d-4c02-ae2b-266c33a289fe@googlegroups.com> Reply-To: nonlegitur@notmyhomepage.de Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 3 Oct 2017 13:25:12 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="f41836b86d45d7c76b77428cfb6b8b4e"; logging-data="30178"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX182Rw0mb6SsQgYrgA2Y1of4U7znzVp6YBQ=" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 In-Reply-To: Content-Language: en-US Cancel-Lock: sha1:BLCRwTeioGhsizTAY9/8TThsdpM= Xref: news.eternal-september.org comp.lang.ada:48316 Date: 2017-10-03T15:25:12+02:00 List-Id: On 03.10.17 12:11, Dmitry A. Kazakov wrote: > It is not very likely you would actually use strings larger than 32K. When a program reads a text file, of size > 32K, into some string ("into memory"), this can make text processing a lot easier. Just think about implementing an abstraction that allows scanning the entire text in case there is no string large enough to contain it. Writing a parser seems less likely and more demanding than feeding a 32+K string to some text processing routine (counting, searching, substituting, ...). There are fewer corner cases to consider, the program does not need state for remembering the previous line's final words, and so forth. > Now if size/bound becomes a type or object property that makes some programs illegal. > > Arguably that could be desirable if the bound comes from the problem space. However in most cases it is just more or less arbitrary design choice which will hit you hard later if you were too generous. > Indeed, suppose designating parts of strings, such as elements or slices, were available through some types more targeted than mere Positive. This choice directly leads to more flexibility, too. For illustration, making Swift 2, 3, and now 4 has included much work on overhauling NSString, so that now, in current Swift, it has become String, and Substring, together with associated types for iteration, slicing, and so forth. String is the aftermath of our own bias when commencing the work of formalization by analyzing our writing. It permeates all programming to an extent that may be in the way of seeing proper abstractions. It's close to making array (Positive range <>) be so ubiquitous that it appears in the public interface of just about any private type. And the above one doesn't, does it?