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=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Community Input for the Maintenance and Revision of the Ada Programming Language Date: Sun, 27 Aug 2017 14:35:59 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <79e06550-67d7-45b3-88f8-b7b3980ecb20@googlegroups.com> <9d4bc8aa-cc44-4c30-8385-af0d29d49b36@googlegroups.com> <1395655516.524005222.638450.laguest-archeia.com@nntp.aioe.org> <4527d955-a6fe-4782-beea-e59c3bb69f21@googlegroups.com> <22c5d2f4-6b96-4474-936c-024fdbed6ac7@googlegroups.com> <3f04ecdc-2672-4051-948f-37ce5446dbac@googlegroups.com> <0950da12-a618-441a-95bb-9ad4c08ce6d9@googlegroups.com> <972e5656-9c05-4f83-bdb3-368e65beeabe@googlegroups.com> <878ti6bxyn.fsf@jacob-sparre.dk> NNTP-Posting-Host: MajGvm9MbNtGBKE7r8NgYA.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; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:47821 Date: 2017-08-27T14:35:59+02:00 List-Id: On 2017-08-27 14:03, Robert Eachus wrote: > On Saturday, August 26, 2017 at 3:48:28 AM UTC-4, Dmitry A. Kazakov wrote: > >> Because see above, URL is not a generalization. It lacks relevant >> properties of a file system, in particular ones for which >> Ada.Directories is meant for, e.g. traversal of the directory tree. URL >> does not tell anything about whether /A/B must exist if /A/B/C does. >> ... >> >> Maybe though it is far away from the direct problems we have with the >> mess of Ada.Directories and Text_IO. > > As I said above, URLs are here to stay, and Ada has to live (or die) > in this world. Again, this all is irrelevant. The sole purpose of Ada.Directories is to traverse the file system nodes. > If parsing file names into directories and (terminal) > objects makes sense, then there is no reason not to continue the current > directory packages, or mark them as obsolete with continued support. Right. Either you do this or you have no Ada.Directories. You want to eliminate it. Good to you. I don't use Ada.Directories either, because it is a non-portable mess. I am using Glib stuff instead. [No, Glib does not confuse files with URLs). > The real problem with the directory stuff is trying to pound reality > into a hierarchical structure. I never ever saw relational or networked file system directory structure, aside from very early academic attempts. The reality is that major file systems are hierarchical. Though string representation is even less suitable for these than for hierarchical topology. > Even on a single Windows, Linux, or Unix > system, the file system is a web with a number of roots which may not be > present at all times or reachable from a given starting point. If root is inaccessible so are its children. > For now, and the next few decades, URLs may not be perfect but they > are what we have. Nobody uses URL for file names, so far. My guess that this will not change in the following decades either. >> And all this cannot change the point: using strings there was a bad >> idea, with URLs or without them. > > No, using strings there was a very valid realization of the DoD > requirements. Ada quickly became an international programming language, > and resolving the character set and path name issues became important. > But throwing out all existing code wasn't going to happen. It happened already. Nobody in sane mind would use Text_IO otherwise that for standard output. Wide_String and Wide_Wide_String variants are not even worth consideration. Lower-level but sane stream I/O to be used instead, yes, with manual handling of encoding and line terminators. Unfortunately record-oriented I/O is long dead. Not that Text_IO handled it better than stream-oriented one. So Stream I/O is a safe, efficient and portable choice, while Text_IO in all its incarnations is anything but. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de