Re: Platform portable support of heir. file systems

[kilgallen@eisner.decus.org (Larry Kilgallen)]

By the way, I agree with another poster's sentiment "If you want
Portable, use Posix".  There have been committees hashing out the
Posix specifications for years, and it seems infeasible to reinvent
the wheel in comp.lang.ada. Nonetheless:

In article <59c7sd$osh@top.mitre.org>, mfb@mbunix.mitre.org (Michael F Brenner) writes:
>>> package url_control is
>>The letters "url" already have a meaning as "universal resource locator"
>>in HTTP
> 
> The url_control package is using url as universal resource locator, but
> is not restricted to being used by http. For example, it is often used 
> for ftp. In addition, it contains a filename, and with certain portions
> of the url blank, it IS a filename. Thus this package is used both on
> a local computer and across the net. In other words, the word url is 
> not being overloaded. It Already has the meaning of being a filename.

No, that is just the point.  It "looks like" a filename for certain
operating systems, but it need not be implemented that way.  If one
were to specify that this Ada package used that URL syntax, then
there could be two different files with identical URLs, depending on
whether one used http or this new package.

>>> function directory_get_first (pattern: urls) return urls;
>>> function directory_get_next   return urls;
>> "Next" using the last pattern used ?  In what context ?  How does one
>> distinguish one directory search from another (comparing the contents
>> of two directories, for instance)?
> 
> Sorry, my telepathy did not transmit through well enough. This is a good
> argument for finding a way to put more semantic information into
> visible parts before Ada-2005 is created. You only have to give the pattern
> once. Get_first and get_next are like an interator which continues until
> the url returned is the null string, which means there are no more 

	stash_into (a, directory_get_first ("directory_a"));
	stash_into (b, directory_get_first ("directory_b"));

Now how do I tell directory_get_next which of those two simultaneously
active directory iterations I want ?

> entries in the current directory which match the pattern. This is the way
> DOS provides access to the directories to avoid data structures that
> force you to read the entire directory into memory at one time so 
> something like an object-oriented iterator would be useable, but at the
> expense of a large amount of wasted RAM.

I can understand that DOS programmers might not bother with separate
contexts simultaneously active, but Ada covers a wider range of operating
systems than DOS.

>>>   function directory_temp return urls;
>> Unique to this thread or just to this executable program ?
>> Shouldn't there be a matching call to delete it ?
> 
> Again, sorry for the missing semantic information. In DOS the temporary
> directory, where the users may create subdirectories which will be 
> deleted by the disk manager, say, every Friday, is called \TMP. In Un*x,

And what if two copies of my program should need such a facility at
the same time?  Why make the individual programmer fight over the
uniqueness issues, which are, after all, highly OS-dependent ?

>>> function end_of_line_string (system: systems := default_system)
>>>                              return string;
>>Since the "url" is an Ada string, I presume this must refer to some
>>sort of separator within a file.  That is a very Unix (or is it C?)
>>chauvenist approach.  By default, VMS files have no such element,
>>and I would doubt that MVS files do either.  A record is a record,
>>delimited by out-of-band mechanisms private to the operating system.
> 
> I used and respected VMS for years with the exception of a component
> called the Record Manager. The Record Manager does not deal with files
> as arrays of characters; IMO this is a design flaw of the Record Manager.

In the opinion of others, it is an advantage.  It is particularly
an advantage in the minds of those who prefer VMS to Unix. Saying
(implicitly) to programmers that "we are going to stuff restrictions
of some other operating system down your throat" while trying to
impress them with Ada is not a winning posture.

>> Your Unix is showing :-).
> Yes, but it is identical in un*x, DOS, NT, etc. Again, the only outlier is
> VMS.

I think MVS and OS/400 are likewise not following your Unix model,
and Microsoft _pretends_ to have invented the world by putting
slashes in the other direction :-).  As for Macintosh, well one
could view the data fork as a stream of bytes, but the resource
fork is something entirely different, with capabilities richer
than VMS and on the file level even richer than OS/400.

>      And VMS is now Posix compliant and is capable of running Posix shells
> at user request.

And Ada is capable of calling Posix services at programmer request :-).

> In all operating systems, there is a way to give the programmer a
> machine independent capability to set global environmental variables,
> using a shared file and an application (object, TSR, process, or whatever)
> that manages that shared file. The question is not how we are going to
> spell the capability in each operating system. The question is how will
> we provide the programmer with a machine independent capability of 
> sending messages to the other programs in the machine. Stating that 
> something called environmental variables works differently in VMS is
> not solving the problem. The set_environment and environment together
> define the interface for a machine independent facility that should be
> provided. How we provide it is a separate (but important) question.

I believe, rather, that it is crucial to support communications with
non-Ada programs as well.

> You suggested environment_table and environment_table_levels as 
> interfaces are interesting. What do the levels mean?

I think that is _way_ beyond the scope of comp.language.ada, but
suffice it to say that the VMS logical name mechanism is _much_
more complex than what would be supported by the simple sequence
you proposed.  Operating systems are different, and that is a fact
of life.  Posix shells have been provided on Windows NT, VMS, MVS,
etc., but most Ada programmers do not have the luxury of saying to
a would-be user of their work "Yes, I can write that in Ada, so
long as users all run in the Posix environment."  As an example,
I would point to the use of the C programming language on VMS,
which is almost always done _outside_ the Posix environment,
calling real VMS system services, etc.  If the C bandwagon
(image of wagon rattling downhill out of control, with contents
falling out) cannot change VMS culture (despite heavy use),
Ada will not either.

Larry Kilgallen