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=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,942b3184b8c0c422 X-Google-Attributes: gid103376,public From: kilgallen@eisner.decus.org (Larry Kilgallen) Subject: Re: Platform portable support of heir. file systems Date: 1996/12/19 Message-ID: <1996Dec19.164901.1@eisner> X-Deja-AN: 204997513 x-nntp-posting-host: eisner.decus.org references: <01bbec7f$453edcd0$24af1486@pc-phw> <1996Dec18.071612.1@eisner> <59b6ea$522@top.mitre.org> <1996Dec19.075644.1@eisner> <59c7sd$osh@top.mitre.org> x-nntp-posting-user: KILGALLEN x-trace: 851032145/15102 organization: LJK Software newsgroups: comp.lang.ada Date: 1996-12-19T00:00:00+00:00 List-Id: 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