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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.129.122.77 with SMTP id v74mr372290ywc.214.1503835394666; Sun, 27 Aug 2017 05:03:14 -0700 (PDT) X-Received: by 10.36.41.68 with SMTP id p65mr151002itp.3.1503835394608; Sun, 27 Aug 2017 05:03:14 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!border1.nntp.ams1.giganews.com!border2.nntp.ams1.giganews.com!nntp.giganews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.am4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!v29no1239523qtv.0!news-out.google.com!c139ni2700itb.0!nntp.google.com!b76no1063871itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 27 Aug 2017 05:03:14 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2601:191:8303:2100:5985:2c17:9409:aa9c; posting-account=fdRd8woAAADTIlxCu9FgvDrUK4wPzvy3 NNTP-Posting-Host: 2601:191:8303:2100:5985:2c17:9409:aa9c 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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Community Input for the Maintenance and Revision of the Ada Programming Language From: Robert Eachus Injection-Date: Sun, 27 Aug 2017 12:03:14 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Body-CRC: 2242925806 X-Received-Bytes: 5911 Xref: news.eternal-september.org comp.lang.ada:47820 Date: 2017-08-27T05:03:14-07:00 List-Id: On Saturday, August 26, 2017 at 3:48:28 AM UTC-4, Dmitry A. Kazakov wrote: > URL may contain such a name, that alone does not make it generalization= =20 > or a desired direction of generalization. Sorry, that ship left port more than a decade ago, and the Ada community is= not big enough, or strong enough to call it back to the dock. There is on= e generalized resource locator worldwide, and it is called a URL. Having said that, the system I am using might represent URLs in Unicode, yo= ur computer might use UTF-8, or some generalized directory structure. It i= s definitely the case that I may use local URLs that cannot be resolved in = that form on your system. Also there will be multiple strings which resolve= to the same resource even starting from the same location on my system, or= yours. So, the right representation of a URL is a private tagged type in Ada. My = system might use Unicode internally, yours might use some generalized file = descriptor in a directory structure doesn't matter. Also, Ada needs to pla= y nicely with ISO 10646, including UTF-8 and Unicode. I would have functions on my system which create URL objects: type Locale is private; function Current_Location return Locale; function To_URL(Path: String) return URL; -- Latin1? Locally defined Charac= ter function To_URL(Path: UTF8) return URL; -- Might just call the above. But -- only if they are the same. function To_URL(Resource: String; Relative_To: Locale) return URL; function To_URL(Path: Long_String) return URL; -- Unicode version function To_URL(Resource: File_Type) return URL; -- Ada IO File_Type function To_URL(Object_Name: Long_String; Relative_To: Locale) return URL; -- I'd probably use this one a lot on a Unicode system. ... procedure Open(Resource: in URL; Mode:=20 Form: ... The various creators for URLs may not all be in the same location (but it m= akes sense for all the language standard defined creators). And please get= it right that you need to be able to create both local and general URLs at= a minimum. One version with locale parameter, one without. =20 > Because see above, URL is not a generalization. It lacks relevant=20 > properties of a file system, in particular ones for which=20 > Ada.Directories is meant for, e.g. traversal of the directory tree. URL= =20 > does not tell anything about whether /A/B must exist if /A/B/C does. >... >=20 > Maybe though it is far away from the direct problems we have with the=20 > mess of Ada.Directories and Text_IO. As I said above, URLs are here to stay, and Ada has to live (or die) in thi= s world. If parsing file names into directories and (terminal) objects mak= es sense, then there is no reason not to continue the current directory pac= kages, or mark them as obsolete with continued support. The real problem with the directory stuff is trying to pound reality into a= hierarchical structure. 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. For now, and the next= few decades, URLs may not be perfect but they are what we have. =20 > And all this cannot change the point: using strings there was a bad=20 > idea, with URLs or without them. No, using strings there was a very valid realization of the DoD requirement= s. 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.