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!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Lower bounds of Strings Date: Wed, 6 Jan 2021 18:17:45 -0600 Organization: JSA Research & Innovation Message-ID: References: <1cc09f04-98f2-4ef3-ac84-9a9ca5aa3fd5n@googlegroups.com> Injection-Date: Thu, 7 Jan 2021 00:17:46 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="7491"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:61051 List-Id: "Dmitry A. Kazakov" wrote in message news:rt3uv2$1nrd$1@gioia.aioe.org... > 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? Built-in to the implementation, of course. Implementing these things in Ada is a nice capability, because that allows simple quick-and-dirty implementations. But for things that are commonly used, that necessarily leads to lousy performance. One has to have at least some special cases even for the Ada.Containers to get adequate performance, so there's no problem extending that. ... > How Stream_Element_Array is supposed to be an opaque container? It should already be an opaque container. You use language-defined stream attributes to implement user-defined stream attributes - not unportable direct byte twiddling. > How file read operation is supposed to assign part of a container? ??? Why would you want to do that? Streaming a bounded vector (which almost all existing arrays should be) naturally would read only the active part of the vector. Non-streaming reading is left over Ada 83 nonsense; all I/O should be built on top of streams (as a practical matter, the vast majority is anyway). > 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. There no reason that a container interface cannot have those things -- Ada.Containers.Vectors does. The things that Vectors is missing (mainly the ability to use enumeration and modular indexes) was a mistake that I complained about repeatedly during the design, but I lost on that. > Array implementation is a fundamental building block of computing. Surely. But one does not need the nonsense of requiring an underlying implementation (which traditional arrays do) in order to get that building block. You always talk about this in terms of an "interface", which is essentially the same idea. One cannot have any sort of non-contigious or persistent arrays with the Ada interface, since operations like assigning into slices are impossible in such representations. One has to give those things up in order to have an "interface" rather than the concrete form for Ada arrays. I prefer to not call the result an array, since an array implies a contiguous in-memory representation. Of course, some vectors will have such a representation, but that needs to be a requirement only for vectors used for interfacing. (And those should be used rarely.) > 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. Compilers implement arrays in Ada; there is no possibility a user doing it. I see no difference between that and having the compiler implement a bounded vector instead as the fundamental building block. You seem fixated on the form of declaration (that is a generic package vs. some sort of built-in syntax) -- there's no fundamental difference. There are many Ada packages that are built-in to compilers (for Janus/Ada, these include System and Ada.Exceptions and Ada.Assertions) -- there's no body or even source of these to be seen. We're not even talking about different syntax for the use of vectors (and it would be easy to have some syntax sugar for declarations - we already have a proposal on those lines for Ada). Indeed, in a new language, one would certainly call these "array" containers (couldn't do that in Ada as the word "array" is reserved). Sometimes, one has to step back and look at the bigger picture and not always at the way things have always been done. Arrays (at least as defined in Ada) have outlived their usefulness. Randy.