Directory listings and path names

Directory listings and path names

[Andreas Valdusson]

If I have the name of a directory, and want ADA to get the names of all
sub-directories of this one, how do I do?
How do I get the contents of a specific directory (ie. the names for all
subdirectories and files) and how do I know which of these that are
sub-directories an which are files?

/Andreas

Re: Directory listings and path names

[M. A. Alves]

On Thu, 17 Jan 2002, Andreas Valdusson wrote:
> If I have the name of a directory, and want ADA to get the names of
> all sub-directories of this one, how do I do? How do I get the
> contents of a specific directory (ie. the names for all subdirectories
> and files) and how do I know which of these that are sub-directories
> an which are files?

These are services of the Operating System, not of Ada (the programming
language), neither of the American Dental Association. You can call the OS
services from an Ada program, thru a _binding_. I bet you can find a
couple of packages implementing such bindings freely available on the
Internet. If you are using GNAT, you already have it: GNAT.OS_Lib :-)

-- 
   ,
 M A R I O   data miner, LIACC, room 221   tel 351+226078830, ext 121
 A M A D O   Rua Campo Alegre, 823         fax 351+226003654
 A L V E S   P-4150-180 PORTO, Portugal    mob 351+939354002

Re: Directory listings and path names

[M. A. Alves]

On Thu, 17 Jan 2002, M. A. Alves wrote:
> . . . GNAT.OS_Lib :-)

See also GNAT.Directory_Operations .

-- 
   ,
 M A R I O   data miner, LIACC, room 221   tel 351+226078830, ext 121
 A M A D O   Rua Campo Alegre, 823         fax 351+226003654
 A L V E S   P-4150-180 PORTO, Portugal    mob 351+939354002

Re: Directory listings and path names

[Joachim Schröer]

Andreas Valdusson wrote:

> If I have the name of a directory, and want ADA to get the names of all
> sub-directories of this one, how do I do?
> How do I get the contents of a specific directory (ie. the names for all
> subdirectories and files) and how do I know which of these that are
> sub-directories an which are files?
> 
> /Andreas
> 
> 
> 


You may download http://www.adapower.com/schroer/lib-src.zip

Look into package portable.operating_system, function all_entries and
set the parameters as you like.
The package is implemented on top of the Ada posix-binding for win32.
In the body some win32 features are called directly.
Simply comment them out if you need the function for another OS than win32.

Best regards

J. Schr�er

Re: Directory listings and path names

[Brian Rogoff]

On Thu, 17 Jan 2002, M. A. Alves wrote:
> On Thu, 17 Jan 2002, Andreas Valdusson wrote:
> > If I have the name of a directory, and want ADA to get the names of
> > all sub-directories of this one, how do I do? How do I get the
> > contents of a specific directory (ie. the names for all subdirectories
> > and files) and how do I know which of these that are sub-directories
> > an which are files?
>
> These are services of the Operating System, not of Ada (the programming
> language),

Says you! I could argue the same about tasking.

IMO, it would be a good thing if there were some sort of standard
directory package. I know, someone will argue that file systems are
different. Oh yeah? So are the multitasking capabilities of various OSes.

> I bet you can find a
> couple of packages implementing such bindings freely available on the
> Internet. If you are using GNAT, you already have it: GNAT.OS_Lib :-)

True, but Ada should provide the support out of the box.

This is one of the first things I need when I start with any programming
language.

-- Brian

Re: Directory listings and path names

[Larry Kilgallen]

In article <Pine.BSF.4.40.0201182253560.954-100000@bpr.best.vwh.net>, Brian Rogoff <bpr@bpr.best.vwh.net> writes:
> On Thu, 17 Jan 2002, M. A. Alves wrote:
>> On Thu, 17 Jan 2002, Andreas Valdusson wrote:
>> > If I have the name of a directory, and want ADA to get the names of
>> > all sub-directories of this one, how do I do? How do I get the
>> > contents of a specific directory (ie. the names for all subdirectories
>> > and files) and how do I know which of these that are sub-directories
>> > an which are files?
>>
>> These are services of the Operating System, not of Ada (the programming
>> language),
> 
> Says you! I could argue the same about tasking.
> 
> IMO, it would be a good thing if there were some sort of standard
> directory package. I know, someone will argue that file systems are
> different. Oh yeah? So are the multitasking capabilities of various OSes.

But a subset of multitasking capabilities has been chosen as being
adequate for Ada programs. Declaring a similar subset for files is
more difficult because files are used for communication with other
components of the computing environment.

Do I want only files that are present on the system or should shelved
files in that directory be included ?  How do I access only the third
newest version (VMS terminology - someone else can translated it into
partitioned data set terminology for IBM machines).    Which of those
file operations are viable on magnetic tape, and which are restricted
to disk files.

Re: Directory listings and path names

[Georg Bauhaus]

Brian Rogoff <bpr@bpr.best.vwh.net> wrote:
 
: True, but Ada should provide the support out of the box.

I don't believe Brian isn't are of this, but the pointer
might still be useful:

From http://www.ada-auth.org/AI-SUMMARY.HTML:

AI95-00248-01/04   2002-01-02 --  Directory Operations
    Priority: Medium     Difficulty: Medium
    Class: Amendment                   Status: Work Item     00-11-28
    RM References:  A.15 (00)  

Re: Directory listings and path names

[Robert A Duff]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> >> These are services of the Operating System, not of Ada (the programming
> >> language),
> > 
> > Says you!

Well, it's true...

>... I could argue the same about tasking.

You can argue what you like, but it would still be false.  ;-)

> > IMO, it would be a good thing if there were some sort of standard
> > directory package. I know, someone will argue that file systems are
> > different. Oh yeah? So are the multitasking capabilities of various OSes.
> 
> But a subset of multitasking capabilities has been chosen as being
> adequate for Ada programs. Declaring a similar subset for files is
> more difficult because files are used for communication with other
> components of the computing environment.

Nonetheless, the ARG is working on a directory operations package.

> Do I want only files that are present on the system or should shelved
> files in that directory be included ?  How do I access only the third
> newest version (VMS terminology - someone else can translated it into
> partitioned data set terminology for IBM machines).    Which of those
> file operations are viable on magnetic tape, and which are restricted
> to disk files.

Well, any interface-to-OS package has to be somewhat
"least-common-denominator"-ish, if it is to be portable.

- Bob

Re: Directory listings and path names

[Brian Rogoff]

On Sat, 19 Jan 2002, Robert A Duff wrote:
> Kilgallen@SpamCop.net (Larry Kilgallen) writes:
>
> > >> These are services of the Operating System, not of Ada (the programming
> > >> language),
> > >
> > > Says you!
>
> Well, it's true...
>
> >... I could argue the same about tasking.
>
> You can argue what you like, but it would still be false.  ;-)

I see that postmodernism and philosophical relativism have not made great
progress in c.l.a ;-)

Surely, we can find many OSes which provide no tasking, some tasking,
sophisticated tasking, etc. I subscribe to the view that what goes in
a language versus what goes in an OS is rather arbitrary. The same is
true for language and library. Library design is language design.

> > > IMO, it would be a good thing if there were some sort of standard
> > > directory package. I know, someone will argue that file systems are
> > > different. Oh yeah? So are the multitasking capabilities of various OSes.
> >
> > But a subset of multitasking capabilities has been chosen as being
> > adequate for Ada programs. Declaring a similar subset for files is
> > more difficult because files are used for communication with other
> > components of the computing environment.
>
> Nonetheless, the ARG is working on a directory operations package.

Yes, and that is a very good thing. The fact that Ada 95 did not provide
such a package has always been a bummer to me. IMO, part of the reason
Ada has failed to make a huge contribution in reusability is that it never
had the prerequisite usability. You can start with Python and immediately
use it for the mundane file munging tasks that many of us need to do,
without having to write your own bindings to the OS. Java also comes with
fairly extensive libraries for this sort of thing.

BTW, I'm speaking of Ada, not GNAT here. GNAT has had a lot of what I want
"out of the box" for a long time, but one of the supposed virtues of Ada
is supposedly portability.

> > Do I want only files that are present on the system or should shelved
> > files in that directory be included ?  How do I access only the third
> > newest version (VMS terminology - someone else can translated it into
> > partitioned data set terminology for IBM machines).

Well, the first thing you have to understand is that VMS is dead :-).

> Well, any interface-to-OS package has to be somewhat
> "least-common-denominator"-ish, if it is to be portable.

Correct. It would also be nice to provide more specific packages, like,
say, Windows, Unix/Posix, Mac (and also rans like VMS, BeOS, Amiga,... :).

-- Brian

Re: Directory listings and path names

[Nick Roberts]

"Brian Rogoff" <bpr@bpr.best.vwh.net> wrote in message
news:Pine.BSF.4.40.0201192225200.74428-100000@bpr.best.vwh.net...

> On Sat, 19 Jan 2002, Robert A Duff wrote:
> > Well, any interface-to-OS package has to be somewhat
> > "least-common-denominator"-ish, if it is to be portable.
>
> Correct. It would also be nice to provide more specific packages, like,
> say, Windows, Unix/Posix, Mac (and also rans like VMS, BeOS, Amiga,... :).

The proposed package will allow implementation-defined children which
provide extra functionality specific to a particular OS or execution
environment.

--
Best wishes,
Nick Roberts

Re: Directory listings and path names

[Stephen Leake]

Brian Rogoff <bpr@bpr.best.vwh.net> writes:

> Surely, we can find many OSes which provide no tasking, some tasking,
> sophisticated tasking, etc. I subscribe to the view that what goes in
> a language versus what goes in an OS is rather arbitrary. The same is
> true for language and library. Library design is language design.

I don't think this is true. The tasking constructs in Ada _cannot_ be
provided by an Ada package; they require compiler support. Thus they
are fundamentally different from directory operations, which clearly
_can_ be provided by a package.

This is separate from the question of whether a directory/file
operations package should be part of the standard. I agree it would be
nice, also hard. Perhaps a good compromise would be for all the Ada
vendors to support the Florist POSIX bindings, on OS's where that is
not too hard.

-- 
-- Stephe

Re: Directory listings and path names

[Marin David Condic]

Not strictly true. Accessing a file system rather implies that there *is* a
file system and hence something vaguely resembling an OS that accesses it.
Tasking, OTOH, can exist on a bare-silicon platform with nothing more than
some sort of Ada RTK that supports the scheduling. (Unless we want to insist
that anything at least as sophisticated as an Ada RTK can be considered an
"Operating System".)

On yet another hand, I do agree that it would be a good idea for Ada to
provide a semi-standard interface to an OS file system. It would necessarily
be reduced to the least common denominator, but with child packages, it
would be possible to isolate interfaces for the most common OS's where there
may be non-portable features in question. Could this be part of the ARM? A
better place to start would be with an informal consensus & see if it might
eventually be something that could migrate to a more formal standard.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Brian Rogoff" <bpr@bpr.best.vwh.net> wrote in message
news:Pine.BSF.4.40.0201182253560.954-100000@bpr.best.vwh.net...
>
> Says you! I could argue the same about tasking.
>
> IMO, it would be a good thing if there were some sort of standard
> directory package. I know, someone will argue that file systems are
> different. Oh yeah? So are the multitasking capabilities of various OSes.
>
> > I bet you can find a
> > couple of packages implementing such bindings freely available on the
> > Internet. If you are using GNAT, you already have it: GNAT.OS_Lib :-)
>
> True, but Ada should provide the support out of the box.
>
> This is one of the first things I need when I start with any programming
> language.
>
> -- Brian
>

Re: Directory listings and path names

[Brian Rogoff]

On 22 Jan 2002, Stephen Leake wrote:
> Brian Rogoff <bpr@bpr.best.vwh.net> writes:
>
> > Surely, we can find many OSes which provide no tasking, some tasking,
> > sophisticated tasking, etc. I subscribe to the view that what goes in
> > a language versus what goes in an OS is rather arbitrary. The same is
> > true for language and library. Library design is language design.
>
> I don't think this is true. The tasking constructs in Ada _cannot_ be
> provided by an Ada package; they require compiler support. Thus they
> are fundamentally different from directory operations, which clearly
> _can_ be provided by a package.

Right, I was misleading. My point was simply that the services that an OS
provides are not fixed in stone, so arguing that one thing or another is
a language feature or an OS feature is pointless. The languages designers
should simply decide what goes into the language.

In any case, believe it or not, lots of people do concurrent programming
in languages without built-in tasking, and rely on library packages to
provide that support.

> This is separate from the question of whether a directory/file
> operations package should be part of the standard. I agree it would be
> nice, also hard. Perhaps a good compromise would be for all the Ada
> vendors to support the Florist POSIX bindings, on OS's where that is
> not too hard.

I think it would be very nice, and not too hard. The Python model works
well enough. Besides, Ada has this wonderful package mechanism, why not
use it to standardize bindings to Unix, Windows, Mac, VMS (see Larry, I
didn't forget you ;), etc? This being 2002, I expect any practical
programming language to have a built-in way to do this. I admit, I'm
Unix/Windows centric. However, the competition is tough, and we're really
talking about very basic functionality that is not being provided.

-- Brian

Re: Directory listings and path names

[Jean-Marc Bourguet]

Brian Rogoff <bpr@bpr.best.vwh.net> writes:

> In any case, believe it or not, lots of people do concurrent programming
> in languages without built-in tasking, and rely on library packages to
> provide that support.

They also rely on their compiler to behave sanely.  I'd not more rely
on a compiler which is not thread aware to build an application with
threads at least in C++ (thinks about exception handling, this is an
area where the generated code can be easily not thread save).

-- 
Jean-Marc

Re: Directory listings and path names

[tmoran]

>Perhaps a good compromise would be for all the Ada
>vendors to support the Florist POSIX bindings,
  Do people prefer the POSIX directory iterator style
    generic
      with procedure Action(...)
    procedure For_Each(Wild_Card_Name_String : in String;...)
that iterates through the directory calling Action on each file, or
do people prefer the IO-ish
  procedure Open
  procedure Get_Next
  procedure Close

Re: Directory listings and path names

[Larry Kilgallen]

In article <6Kh38.35040$YM1.1631665254@newssvr21.news.prodigy.com>, tmoran@acm.org writes:
>>Perhaps a good compromise would be for all the Ada
>>vendors to support the Florist POSIX bindings,
>   Do people prefer the POSIX directory iterator style
>     generic
>       with procedure Action(...)
>     procedure For_Each(Wild_Card_Name_String : in String;...)
> that iterates through the directory calling Action on each file, or
> do people prefer the IO-ish
>   procedure Open
>   procedure Get_Next
>   procedure Close

I find the second style better when I am doing uncommon things,
such as looking for all files of which there are fewer than 3
versions.

Re: Directory listings and path names

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 898 bytes --]


"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> a �crit dans le message news: > On yet another hand, I do agree that
it would be a good idea for Ada to
> provide a semi-standard interface to an OS file system. It would necessarily
> be reduced to the least common denominator
Not necessarily. Have a look at package OS_Services from Adalog's component page (http://www.adalog.fr/compo2.htm) for a system that
allows a lot of flexibility. It achieves the following goal:
- if functionnality XYZ is provided, it works independently of the OS
- if functionnality XYZ is *not* provided (and you need it), it doesn't compile.

In short, a program will work on any platform that supports the functionnalities needed by the program.
--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Directory listings and path names

[Marin David Condic]

Thanks. I'll take a look at it.

I can see value in trying to create the most flexible interface possible but
I think you'd have to admit that there are some features of OS #1 that are
just simply not going to exist or even make sense under OS #2. In some of
those cases, you might be able to get clever and find a way to keep those
features from compiling under OS #2, but I could still see it as being
particularly attractive to say "Here's a set of features that make sense for
(almost) any operating system under package name X and here are features
that only make sense or are supported by OS #1 under package name X.OS_1,
etc..." That way, you can develop code that is OS independent if you like
*or* take advantage of peculiarities of a particular OS through an interface
you feel comfortable will be there for (almost) any Ada implementation that
targets that particular system.

Clearly, whatever can be made OS independent, ought to be. But there are
reasons why, sometimes, Windows is better for something than Unix or has
features that won't exist in any form under Unix, etc.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Jean-Pierre Rosen" <rosen@adalog.fr> wrote in message
news:a2mf2e$h1q$1@s1.read.news.oleane.net...
>
> Not necessarily. Have a look at package OS_Services from Adalog's
component page (http://www.adalog.fr/compo2.htm) for a system that
> allows a lot of flexibility. It achieves the following goal:
> - if functionnality XYZ is provided, it works independently of the OS
> - if functionnality XYZ is *not* provided (and you need it), it doesn't
compile.
>
> In short, a program will work on any platform that supports the
functionnalities needed by the program.

Re: Directory listings and path names

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]


"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> a �crit dans le message news: > I can see value in trying to create
the most flexible interface possible but
> I think you'd have to admit that there are some features of OS #1 that are
> just simply not going to exist or even make sense under OS #2. In some of
> those cases, you might be able to get clever and find a way to keep those
> features from compiling under OS #2, but I could still see it as being
> particularly attractive to say "Here's a set of features that make sense for
> (almost) any operating system under package name X and here are features
> that only make sense or are supported by OS #1 under package name X.OS_1,
> etc..." That way, you can develop code that is OS independent if you like
> *or* take advantage of peculiarities of a particular OS through an interface
> you feel comfortable will be there for (almost) any Ada implementation that
> targets that particular system.
Agreed. And I hope my design allows this. Have a look at it, then I'll be pleased to respond to any "How do I..." you may have.

--
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Directory listings and path names

[Mark Biggar]

Marin David Condic wrote:
> On yet another hand, I do agree that it would be a good idea for Ada to
> provide a semi-standard interface to an OS file system. It would necessarily
> be reduced to the least common denominator, but with child packages, it
> would be possible to isolate interfaces for the most common OS's where there
> may be non-portable features in question. Could this be part of the ARM? A
> better place to start would be with an informal consensus & see if it might
> eventually be something that could migrate to a more formal standard.

There is already an amendment AI for this.  See AI95-00248-01
on http://www.ada-auth.org/AI-SUMMARY.HTML

--
Mark Biggar
mark.a.biggar@attbi.com

Re: Directory listings and path names

[Marin David Condic]

It looks interesting - although my inspection of it was rather cursory. It
seems to center on Windows/Unix which, of course, covers a lot of turf. I'm
wondering how well it would fit with more niche-type OS's and/or possible
future developments in the field. (Would it fit well with MacOS, for
example - or manipulating URLs/URIs?)

While a positive thing, it may need some broadening of scope. You get more
from an OS than just directories and files & it would be nice to have a
common way of getting at some of those services. Like I said, not everything
could be standard because there are features that may or may not be
supported, so maybe provisions for OS specific packages would still be in
order.

I could come up with a laundry list.... :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Mark Biggar" <mark.a.biggar@attbi.com> wrote in message
news:3C4EF2AA.31A78C84@attbi.com...
>
> There is already an amendment AI for this.  See AI95-00248-01
> on http://www.ada-auth.org/AI-SUMMARY.HTML
>

Re: Directory listings and path names

[tmoran]

>wondering how well it would fit with more niche-type OS's and/or possible
>future developments in the field. (Would it fit well with MacOS, for
>example - or manipulating URLs/URIs?)
  The whole idea of directories and paths presumes a tree structure.
URLs are more like unique names, where '/' is just another character.
"a.com/b/c*.htm" is not meaningful as a URL (unless of course the server
wants to give "b/c*.htm" some meaning).  Tree structured directories
date from the days of tree structured databases.  They will eventually
disappear.  Then people will want standardized packages to handle
URLs and organize related URLs.  In the meantime, let's standardize at
least the simplest, least common denominator, directory walking routines.
IMHO

Re: Directory listings and path names

[Robert A Duff]

tmoran@acm.org writes:

>...  Tree structured directories
> date from the days of tree structured databases.  They will eventually
> disappear.

I hope not!

- Bob

Re: Directory listings and path names

[Darren New]

tmoran@acm.org wrote:
>   The whole idea of directories and paths presumes a tree structure.

The only reasonable way to split up a data structure that crosses
administrative domain boundaries is via a tree structure.

> URLs are more like unique names, where '/' is just another character.

Errr, no. URLs are tree structured.

> "a.com/b/c*.htm" is not meaningful as a URL (unless of course the server
> wants to give "b/c*.htm" some meaning).

It is, if you escape the "*". (Of course, you'll have a literal "*" in
the URL then.)

> Tree structured directories
> date from the days of tree structured databases.  They will eventually
> disappear.

I'm not holding my breath. ;-)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
  The opposite of always is sometimes.
   The opposite of never is sometimes.

Re: Directory listings and path names

[Marin David Condic]

My thinking on URLs is that as a "Uniform Resource Locator" they could be
used as a kind of "File System" - directory tree structured or not. Hence,
there might be some desire to do things like copying resources, deleting
them, etc. I don't know of an OS that specifies its files with URL syntax -
but given "The Net" and similar directions in computer software, it seems
like something that might come up.

I don't object to getting an Ada package that deals only with more
traditional tree structured directories or only a few common file systems.
What I'm suggesting is that in the process of talking about such a creature
that possibly some thought be given to reasonable future needs. If its
useful, people will want to expand its capabilities.

Obviously, unless Ada develops its own abstraction for a "File System" or a
full-blown OS, (something that could be mapped to some/most existing OS's -
similar to how Tasking is a kind of abstraction that can be mapped to most
OS multitasking facilities) anything it does to connect to such services is
going to be rather system dependend and non-portable. Trying to come up with
such an abstraction would be a big job. Anything less is still more than we
have now, so its not something I'd discourage.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


<tmoran@acm.org> wrote in message
news:flF38.35525$%51.1922466961@newssvr21.news.prodigy.com...
>   The whole idea of directories and paths presumes a tree structure.
> URLs are more like unique names, where '/' is just another character.
> "a.com/b/c*.htm" is not meaningful as a URL (unless of course the server
> wants to give "b/c*.htm" some meaning).  Tree structured directories
> date from the days of tree structured databases.  They will eventually
> disappear.  Then people will want standardized packages to handle
> URLs and organize related URLs.  In the meantime, let's standardize at
> least the simplest, least common denominator, directory walking routines.
> IMHO

Re: Directory listings and path names

[Nick Roberts]

"Mark Biggar" <mark.a.biggar@attbi.com> wrote in message
news:3C4EF2AA.31A78C84@attbi.com...
> ...
> There is already an amendment AI for this.  See AI95-00248-01
> on http://www.ada-auth.org/AI-SUMMARY.HTML

The latest version is AI95-00248-04 and this may be updated (e.g. with some
of my own suggestions ;-) People reading this thread, do please take a look
at this AI, and make any (reasonable) suggestions you may have.

The theme of the proposal is to provide a fairly minimal, lowest common
denominator, set of operations relating to files and directories.

It is certainly intended to be as operating-system independent as possible;
however, some weight must surely be given to the predominance of UNIX and
MS-DOS/Windows, and the many variants whose file and directory facilities
are based upon or similar to them.

--
Best wishes,
Nick Roberts

Re: Directory listings and path names

[M. A. Alves]

On Wed, 23 Jan 2002, Marin David Condic wrote:
> My thinking on URLs is that as a "Uniform Resource Locator" they could be
> used as a kind of "File System" . . .

Yes. I have in my "to do" list an examination of the IOS (Internet
Operating System) (associated with the REBOL language I think) to see if
they have acomplished that.

-- 
   ,
 M A R I O   data miner, LIACC, room 221   tel 351+226078830, ext 121
 A M A D O   Rua Campo Alegre, 823         fax 351+226003654
 A L V E S   P-4150-180 PORTO, Portugal    mob 351+939354002

Re: Directory listings and path names

[Brian Rogoff]

On Tue, 22 Jan 2002, Marin David Condic wrote:
> Not strictly true. Accessing a file system rather implies that there *is* a
> file system and hence something vaguely resembling an OS that accesses it.
> Tasking, OTOH, can exist on a bare-silicon platform with nothing more than
> some sort of Ada RTK that supports the scheduling. (Unless we want to insist
> that anything at least as sophisticated as an Ada RTK can be considered an
> "Operating System".)

You're just nitpicking. The important point is not whether file system
access is provided by the core language but whether it is in the standard.
Ada has an Information Systems annex but no hierarchical file systems
annex. I think the latter is at least as important as the former. Sure,
its easy enough to come up with a package but we all understand the
benefit of a standard, don't we.

Anyways, I know about the AI and I'm just making noise :-). I usually make
noise about things which will sadly never change about Ada. However, this
is really low hanging fruit and it is a shame that we don't have it now!

-- Brian

Re: Directory listings and path names

[tgingold]

In article <a2nh21$125l0q$1@ID-25716.news.dfncis.de>, Nick Roberts wrote:
> "Mark Biggar" <mark.a.biggar@attbi.com> wrote in message
> news:3C4EF2AA.31A78C84@attbi.com...
>> ...
>> There is already an amendment AI for this.  See AI95-00248-01
>> on http://www.ada-auth.org/AI-SUMMARY.HTML
> 
> The latest version is AI95-00248-04 and this may be updated (e.g. with some
> of my own suggestions ;-) People reading this thread, do please take a look
> at this AI, and make any (reasonable) suggestions you may have.
I don't know where suggestions should be made, but here is mine:

  function Full_Name (Name : in String) return String;
    Returns the full name corresponding to the file name specified by Name. 
    [...]

Should be *a* full name, since some systems (such as UNIX) doesn't have only
one name for a file (links).
Therefore, this function cannot be used to canonicalize a file name.

Tristan.

Re: Directory listings and path names

[Larry Kilgallen]

In article <a2r2vk$1mni$1@mo5.fr.ipricot.com>, tgingold@pc204.ipricot.fr writes:

>   function Full_Name (Name : in String) return String;
>     Returns the full name corresponding to the file name specified by Name. 
>     [...]
> 
> Should be *a* full name, since some systems (such as UNIX) doesn't have only
> one name for a file (links).
> Therefore, this function cannot be used to canonicalize a file name.

Whereas on VMS there may be multiple full names, equally valid for
accessing the file, but one of them is "more equal" and often used
for special purposes that require a canonical name.

Re: Directory listings and path names

[Marin David Condic]

I agree that it is really low hanging fruit to establish a package spec and
declare it to be a de facto standard. Especially for something that doesn't
involve a half-million lines of code to implement and can be reasonably
supported on most operating systems.

There's no reason that it has to even wait for a language revision. It could
be viewed this way: If the package spec outlined in the AI for file
manipulation is reasonably complete and the various Ada vendors simply
started shipping it with their product, then it effectively becomes an
informal part of the language. Doing so allows for some experimentation and
experience to be built up with it such that when the time comes to include
it in a future standard, it will be well understood and reliable.

I would go further to say that there are probably a large number of such
packages that could be candidates for such an inclusion. And I don't think
that they necessarily have to be in an annex of the ARM if the reigning view
is that it is too hard to write a formal specification that can be used for
validation. A reference implementation might be sufficient so long as it is
widely adopted. The point being that the more things that a developer can
leverage in building applications, the more useful the language becomes and
the easier it is to adopt. If other languages provide libraries of useful
stuff and Ada doesn't out of some sense of strict adherence to formal
validation, then other languages will get used and Ada will not. Why wait
for Ada0X?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Brian Rogoff" <bpr@bpr.best.vwh.net> wrote in message
news:Pine.BSF.4.40.0201250010340.88868-100000@bpr.best.vwh.net...
>
> Anyways, I know about the AI and I'm just making noise :-). I usually make
> noise about things which will sadly never change about Ada. However, this
> is really low hanging fruit and it is a shame that we don't have it now!
>