Re: Community Input for the Maintenance and Revision of the Ada Programming Language

[Robert Eachus <rieachus@comcast.net>]

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 
> 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 one generalized resource locator worldwide, and it is called a URL.

Having said that, the system I am using might represent URLs in Unicode, your computer might use UTF-8, or some generalized directory structure.  It is 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 play 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 Character
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: 
               Form: ...

The various creators for URLs may not all be in the same location (but it makes 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.
 
> 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.  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.

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.
 
> 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.