* Re: Environment variables
1996-10-30 0:00 ` David Emery
@ 1996-10-30 0:00 ` Laurent Guerby
1996-11-02 0:00 ` Keith Thompson
1996-10-30 0:00 ` Robert Dewar
` (5 subsequent siblings)
6 siblings, 1 reply; 39+ messages in thread
From: Laurent Guerby @ 1996-10-30 0:00 UTC (permalink / raw)
Robert> If you are using GNAT, take a look at GNAT.OS_Lib.Getenv in
Robert> file g-os_lib.ads (there are lots of useful routines in this
Robert> package :-)
There's also Ada.Command_Line.Environment.
--
Laurent Guerby <guerby@gnat.com>, Team Ada.
"Use the Source, Luke. The Source will be with you, always (GPL)."
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Environment variables
1996-10-30 0:00 ` Laurent Guerby
@ 1996-11-02 0:00 ` Keith Thompson
0 siblings, 0 replies; 39+ messages in thread
From: Keith Thompson @ 1996-11-02 0:00 UTC (permalink / raw)
In <ws94tjbhlg1.fsf@schonberg.cs.nyu.edu> guerby@gnat.com (Laurent Guerby) writes:
> There's also Ada.Command_Line.Environment.
Remember that, though Ada.Command_Line is a language-defined package,
Ada.Command_Line.Environment is not.
--
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
FIJAGDWOL
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Environment variables
1996-10-30 0:00 ` David Emery
1996-10-30 0:00 ` Laurent Guerby
@ 1996-10-30 0:00 ` Robert Dewar
1996-11-01 0:00 ` Laurent Guerby
` (4 subsequent siblings)
6 siblings, 0 replies; 39+ messages in thread
From: Robert Dewar @ 1996-10-30 0:00 UTC (permalink / raw)
">All I want to do is to be able to read the value of environment
>variables, such as PATH for example. I've looked around at FAQ's and the
>adahome reference pages, but I haven't found anything."
If you are using GNAT, take a look at GNAT.OS_Lib.Getenv in file
g-os_lib.ads (there are lots of useful routines in this package :-)
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Environment variables
1996-10-30 0:00 ` David Emery
1996-10-30 0:00 ` Laurent Guerby
1996-10-30 0:00 ` Robert Dewar
@ 1996-11-01 0:00 ` Laurent Guerby
1996-11-02 0:00 ` Robert A Duff
1996-11-02 0:00 ` Robert Dewar
1996-11-01 0:00 ` Norman H. Cohen
` (3 subsequent siblings)
6 siblings, 2 replies; 39+ messages in thread
From: Laurent Guerby @ 1996-11-01 0:00 UTC (permalink / raw)
Laurent> There's also Ada.Command_Line.Environment.
Stephen> This package is in gnat, but it does not seem to be in the
Stephen> RM, at least, not in the index or appendix A. Is it Ada 95
Stephen> standard, or a gnat extension? The source doesn't say either;
Stephen> do the sources of gnat extensions indicate that they are
Stephen> extensions?
It's a GNAT extension. Note that, technically speaking, it's legal
for an implementation to provide a completly different
Ada.Command_Line than the one listed in the RM, as per RM-A.15(21):
RM> Implementation Permissions
RM>
RM> 21 An alternative declaration is allowed for package Command_Line if
RM> different functionality is appropriate for the external execution
RM> environment.
You can tell if one source is coming from the standard or from GNAT
by looking at the header, the GNAT stuff is GPL'ed (plus extra
permission) and the RM stuff headers look like:
------------------------------------------------------------------------------
-- --
-- GNAT RUNTIME COMPONENTS --
-- --
-- A D A . C O M M A N D _ L I N E --
-- --
-- S p e c --
-- --
-- $Revision: 1.8 $ --
-- --
-- This specification is adapted from the Ada Reference Manual for use with --
-- GNAT. In accordance with the copyright of that document, you can freely --
-- copy and modify this specification, provided that if you redistribute a --
-- modified version, any changes that you have made are clearly indicated. --
-- --
------------------------------------------------------------------------------
--
Laurent Guerby <guerby@gnat.com>, Team Ada.
"Use the Source, Luke. The Source will be with you, always (GPL)."
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Environment variables
1996-11-01 0:00 ` Laurent Guerby
@ 1996-11-02 0:00 ` Robert A Duff
1996-11-02 0:00 ` Robert Dewar
1 sibling, 0 replies; 39+ messages in thread
From: Robert A Duff @ 1996-11-02 0:00 UTC (permalink / raw)
In article <ws9aft1vgse.fsf@schonberg.cs.nyu.edu>,
Laurent Guerby <guerby@gnat.com> wrote:
>...Note that, technically speaking, it's legal
>for an implementation to provide a completly different
>Ada.Command_Line than the one listed in the RM, as per RM-A.15(21):
Only if it is "appropriate" to do so. ;-)
>RM> Implementation Permissions
>RM>
>RM> 21 An alternative declaration is allowed for package Command_Line if
>RM> different functionality is appropriate for the external execution
>RM> environment.
- Bob
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Environment variables
1996-11-01 0:00 ` Laurent Guerby
1996-11-02 0:00 ` Robert A Duff
@ 1996-11-02 0:00 ` Robert Dewar
1 sibling, 0 replies; 39+ messages in thread
From: Robert Dewar @ 1996-11-02 0:00 UTC (permalink / raw)
Laurent said
' It's a GNAT extension. Note that, technically speaking, it's legal
for an implementation to provide a completly different
Ada.Command_Line than the one listed in the RM, as per RM-A.15(21):"
This is true, but quite irrelevant. The issue here is providing
implementation defined grandchildren of Ada, which is always permitted,
without needing to appeal to special provisions.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Environment variables
1996-10-30 0:00 ` David Emery
` (2 preceding siblings ...)
1996-11-01 0:00 ` Laurent Guerby
@ 1996-11-01 0:00 ` Norman H. Cohen
1996-11-01 0:00 ` David Shochat
` (2 subsequent siblings)
6 siblings, 0 replies; 39+ messages in thread
From: Norman H. Cohen @ 1996-11-01 0:00 UTC (permalink / raw)
Laurent Guerby wrote:
> Robert> If you are using GNAT, take a look at GNAT.OS_Lib.Getenv in
> Robert> file g-os_lib.ads (there are lots of useful routines in this
> Robert> package :-)
>
> There's also Ada.Command_Line.Environment.
Note (1) that this is a GNAT-only child of Ada.Command_Line and (2) that
this package only gives you access to a sequence of strings such as
"GNAT_DIR=D:\ADA\gnat304a", leaving you to do the work of finding a
string with a given name before the '=' and extracting the value after
the '='.
--
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Environment variables
1996-10-30 0:00 ` David Emery
` (3 preceding siblings ...)
1996-11-01 0:00 ` Norman H. Cohen
@ 1996-11-01 0:00 ` David Shochat
1996-11-02 0:00 ` Larry Kilgallen
1996-11-01 0:00 ` Environment variables Stephen Leake
1996-11-05 0:00 ` David Emery
6 siblings, 1 reply; 39+ messages in thread
From: David Shochat @ 1996-11-01 0:00 UTC (permalink / raw)
This whole thread is making me rather sick. I was recently involved with
an effort involving porting a good bit of Ada 83 code to Ada 95, in
which the necessary conversion of X-windows code from "AXI Bindings" to
"Intermetrics Bindings" was fairly massive and non-trivial.
My point is that things like reading environment variables should be
standardized. On our project we have tried to stick to the POSIX
packages (Forest for us -- the newer one wasn't available when we
started) for Unix interface functions which aren't standardized in the
RM. When a C programmer wants to read environment variables, she doesn't
have to choose among 6 different interfaces and worry about what happens
when she moves the code to a different vendor's compiler etc. I know
reading environment variables is an extremely exercise in pragma Import,
but this sort of thing should just be there to use. As it is for the C
programmer (regardless of whose compiler he is using).
..Sigh
-- David
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Environment variables
1996-11-01 0:00 ` David Shochat
@ 1996-11-02 0:00 ` Larry Kilgallen
1996-11-04 0:00 ` Michael F Brenner
0 siblings, 1 reply; 39+ messages in thread
From: Larry Kilgallen @ 1996-11-02 0:00 UTC (permalink / raw)
In article <327A32A3.2DD0@itg-sepg.logicon.com>, David Shochat <shochat@itg-sepg.logicon.com> writes:
> This whole thread is making me rather sick. I was recently involved with
> an effort involving porting a good bit of Ada 83 code to Ada 95, in
> which the necessary conversion of X-windows code from "AXI Bindings" to
> "Intermetrics Bindings" was fairly massive and non-trivial.
>
> My point is that things like reading environment variables should be
> standardized. On our project we have tried to stick to the POSIX
> packages (Forest for us -- the newer one wasn't available when we
> started) for Unix interface functions which aren't standardized in the
> RM.
Although some may be able to limit use of their projects to running in a
Posix environment, not every project can live with that constraint. Aside
from Unix systems, most Posix environments are separate environments from
the native environment for a platform, and often there are requirements to
use X-windows outside the Posix environment. The particular example of
"environment variables" does not make sense outside Posix/Unix, so those
who have been bitten once by a portability issue should consider future
porting requirements as well.
Larry Kilgallen
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Environment variables
1996-11-02 0:00 ` Larry Kilgallen
@ 1996-11-04 0:00 ` Michael F Brenner
1996-11-04 0:00 ` Larry Kilgallen
1996-11-12 0:00 ` Robert Dewar
0 siblings, 2 replies; 39+ messages in thread
From: Michael F Brenner @ 1996-11-04 0:00 UTC (permalink / raw)
Larry Kilgallen said:
> The particular example of
> "environment variables" does not make sense outside Posix/Unix, so those
> who have been bitten once by a portability issue should consider future
> porting requirements as well.
It might be good to consider that environment variables make sense in DOS,
DOS with PharLap extender, DOS with Desqview extender, DOS with Desqview/X
extender, Windows NT, OS/2, VxWorks, and other operating systems. Are there
any operating systems or remote target (embedded) runtime systems that
do not provide environment variables?
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Environment variables
1996-11-04 0:00 ` Michael F Brenner
@ 1996-11-04 0:00 ` Larry Kilgallen
1996-11-12 0:00 ` Robert Dewar
1 sibling, 0 replies; 39+ messages in thread
From: Larry Kilgallen @ 1996-11-04 0:00 UTC (permalink / raw)
In article <55kmb1$3m6@top.mitre.org>, mfb@mbunix.mitre.org (Michael F Brenner) writes:
> Larry Kilgallen said:
> > The particular example of
> > "environment variables" does not make sense outside Posix/Unix, so those
> > who have been bitten once by a portability issue should consider future
> > porting requirements as well.
>
> It might be good to consider that environment variables make sense in DOS,
> DOS with PharLap extender, DOS with Desqview extender, DOS with Desqview/X
> extender, Windows NT, OS/2, VxWorks, and other operating systems. Are there
> any operating systems or remote target (embedded) runtime systems that
> do not provide environment variables?
VMS, MacOS and MVS do not have "environment variables" with their
native user environments. Naturally they all have them in their
Posix environments (or Unix emulators). But some requirements
may preclude running within those Posix/Unix subsystems.
Naturally all these operating systems have something "just as good
as" environment variables, but all subtly different. In the case
of VMS, both the logical name mechanism and the DCL symbol mechanism
have some of the qualities of environment variables, but neither is
an exact match.
Are you sure that the non-Unix operating systems listed all ascribe
semantics to "environment variables" which have the same meaning and
scope as those for Unix ? Certainly the goal is not to access just
any construct an operating system vendor might have named "environment
variables".
Larry Kilgallen
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Environment variables
1996-11-04 0:00 ` Michael F Brenner
1996-11-04 0:00 ` Larry Kilgallen
@ 1996-11-12 0:00 ` Robert Dewar
1996-11-13 0:00 ` Norman H. Cohen
1996-11-14 0:00 ` Standard libraries (Was: Environment variables) Geert Bosch
1 sibling, 2 replies; 39+ messages in thread
From: Robert Dewar @ 1996-11-12 0:00 UTC (permalink / raw)
Michael said
"It might be good to consider that environment variables make sense in DOS,
DOS with PharLap extender, DOS with Desqview extender, DOS with Desqview/X
extender, Windows NT, OS/2, VxWorks, and other operating systems. Are there
any operating systems or remote target (embedded) runtime systems that
do not provide environment variables?"
Very few remote target (embedded) runtime systems have environment
variables and many operating systems do not. If they were standard
they would be in the standard libraries.
They are standard in ANSI, but with entirely implementation defined
semantics.
ANSI => ANSI C
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Environment variables
1996-11-12 0:00 ` Robert Dewar
@ 1996-11-13 0:00 ` Norman H. Cohen
1996-11-14 0:00 ` Standard libraries (Was: Environment variables) Geert Bosch
1 sibling, 0 replies; 39+ messages in thread
From: Norman H. Cohen @ 1996-11-13 0:00 UTC (permalink / raw)
Robert Dewar wrote:
> Very few remote target (embedded) runtime systems have environment
> variables and many operating systems do not. If they were standard
> they would be in the standard libraries.
>
> They are standard in ANSI, but with entirely implementation defined
> semantics.
> ANSI => ANSI C
The ANSI C standard specifically acknowledges that the C standard
library need not be supported on an embedded target. Section 2.1.2
defines two kinds of execution environments, "hosted" and
"freestanding". Subsection 2.1.2.1 describes a freestanding environment
as follows:
In a freestanding environment (in which C program execution
may take place without benefit of an operating system), the name
and type of the function called at program startup are
implementation-defined. There are otherwise no reserved external
identifiers. Any library facilities available to a freestanding
program are implementation-defined.
--
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen
^ permalink raw reply [flat|nested] 39+ messages in thread
* Standard libraries (Was: Environment variables)
1996-11-12 0:00 ` Robert Dewar
1996-11-13 0:00 ` Norman H. Cohen
@ 1996-11-14 0:00 ` Geert Bosch
1996-11-14 0:00 ` Robert Dewar
1 sibling, 1 reply; 39+ messages in thread
From: Geert Bosch @ 1996-11-14 0:00 UTC (permalink / raw)
Robert Dewar (dewar@merv.cs.nyu.edu) wrote:
"Very few remote target (embedded) runtime systems have environment
variables and many operating systems do not. If they were standard
they would be in the standard libraries. "
You could say the same of package Ada.Command_Line. The important point
is, IMHO, that a reasonable number of different platforms (Dos, Unix,
Windows, OS/2, Mac) which represent a significant share (90%?) of the
potential Ada users have this same problem. That is a good enough
reason to have some form of standard interface.
I do not say that this functionality (including Ada.Command_Line)
should be part of the standardized Ada language. Issues like these are
very well suited to less formal standardizing, like including extra
functionality in the GNAT standard libraries. These might perhaps be
separated from the Ada.* hierarchy in an Extra.* hierarchy.
Given the significant use of GNAT in proportion to other Ada-95
compilers, an initiative (supported) by the developers of GNAT in this
direction might be followed by others and become a de facto standard.
Important areas to be covered by such an extension would be:
* Terminal IO including cursor positioning commands and attribute
changes. Of course these should be stored with each Terminal_IO file
opened, so multiple tasks can maintain there own position/attributes
without interfering with other tasks using the same terminal.
* File-system support for changing current directory, querying
information about files in the current directory and
deleting/renaming files.
* Network IO which would at least support (a subset of) populair
TCP/IP networking, so there is a common way of communicating
between computers connected to the Internet.
These are points that have very much in common on the major platforms
like Dos, Unix, OS/2, Macintosh and Windows, although not all platforms
will have standard support for all areas.
This is no reason however to *not* make *any* attempt to standardize
on these very common external interfaces. Many programs only need
the very simple common features described above which can have good
portability between platforms.
Is it really necessary that every Ada user invents his own
ANSI-emulator? Should everybody make his own platform-specific
procedure for deleting an external file?
Is that what code reuse is all about?
I suggest that we, as Ada users and c.l.a. readers/writers, make
an effort to standardize on specifications for these interfaces.
Implementing them is easy enough.
Regards,
Geert
--
E-Mail: geert@sun3.iaf.nl
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Standard libraries (Was: Environment variables)
1996-11-14 0:00 ` Standard libraries (Was: Environment variables) Geert Bosch
@ 1996-11-14 0:00 ` Robert Dewar
1996-11-16 0:00 ` Geert Bosch
0 siblings, 1 reply; 39+ messages in thread
From: Robert Dewar @ 1996-11-14 0:00 UTC (permalink / raw)
Geert says
"You could say the same of package Ada.Command_Line. The important point
is, IMHO, that a reasonable number of different platforms (Dos, Unix,
Windows, OS/2, Mac) which represent a significant share (90%?) of the
potential Ada users have this same problem. That is a good enough
reason to have some form of standard interface.
I do not say that this functionality (including Ada.Command_Line)
should be part of the standardized Ada language. Issues like these are
very well suited to less formal standardizing, like including extra
functionality in the GNAT standard libraries. These might perhaps be
separated from the Ada.* hierarchy in an Extra.* hierarchy."
Can you please explain why the approved IEEE POSIX-Ada binding, which has
this functionality, as well as all the other functionality you go on to
describe in your note, does not EXACTLY meet this requirement, in EXACTLY
the manner that you recommend?
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Standard libraries (Was: Environment variables)
1996-11-14 0:00 ` Robert Dewar
@ 1996-11-16 0:00 ` Geert Bosch
1996-11-16 0:00 ` Robert Dewar
0 siblings, 1 reply; 39+ messages in thread
From: Geert Bosch @ 1996-11-16 0:00 UTC (permalink / raw)
Robert Dewar wrote:
"Can you please explain why the approved IEEE POSIX-Ada binding, which has
this functionality, as well as all the other functionality you go on to
describe in your note, does not EXACTLY meet this requirement, in EXACTLY
the manner that you recommend? "
As far as I have seen (looking at forest, I don't have the standard you
mention as it is not public) this binding is very Unix specific and
only meant for Unix systems. So rather than defining an interface that
defines a consistent subset of the functionality most common platforms
have, it takes one (Unix) and wraps a thin layer around the standard C
library so it can be used in Ada.
Instead of providing functions to set a file to read-only or read-write
permissions, you can only set group, user and others access bits a-la
Unix.
If I want to write a cross-platform application that write-protects a file
(for example during compilation) I want a way to specify that somehow.
Having to use a group/owner/others set of permissions just doesn't make
sense on other platforms. However it *does* make sense to write-protect
a file in Unix, or to reset the rights to read/write. In the first case
the Unix file mode is set like "chmod a-r" and in the second case file
attributes are reset to the defaults as determined by the environment
(UMASK in Unix).
What I want is to have an interface that *increases* portability by
specifying the common functionality of several major platforms. That
way I know that I'm using a portable subset. If I need platform-specific
features like sending a process a -SIGSTOP signal, then I could use
the POSIX library. What does it mean to Unlink a file?
The POSIX standard just is based on Unix implementation details like
the Unix file-system using group/user/world permissions and i-nodes,
It will be really hard to write a program using for example forest and
not relying on a Unix implementation.
Maybe I'm wrong and POSIX means Portable Operating System Interface for
Computer Environments after all. But a comment in the Available
Ada Bindings report from the AI&C tells more about the standard:
"The POSIX program grew from the effort by Unix users to develop
a "standard" definition of the Unix system interface. "
I don't think it has grown much beyond that. There is a *huge* gap
between the very clear, cross-platform standard Ada library that uses
good Ada-style abstractions and the C-oriented Unix API put into an Ada
coat.
Don't get me wrong, I really like it that there is at least a good
interface for Unix programs available, which maybe even might run on
other systems using a Unix-emulation layer. Using the Unix API for
writing programs that should also run in DOS however is abstraction
inversion IMHO. You'll get a program that is barely readable and hard
to maintain, because it relies very much on implementation details of
Unix and the Unix-emulation layer.
Regards,
Geert
--
E-Mail: geert@sun3.iaf.nl
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Standard libraries (Was: Environment variables)
1996-11-16 0:00 ` Geert Bosch
@ 1996-11-16 0:00 ` Robert Dewar
1996-11-17 0:00 ` Geert Bosch
0 siblings, 1 reply; 39+ messages in thread
From: Robert Dewar @ 1996-11-16 0:00 UTC (permalink / raw)
Geert said
'As far as I have seen (looking at forest, I don't have the standard you
mention as it is not public) this binding is very Unix specific and
only meant for Unix systems. So rather than defining an interface that
defines a consistent subset of the functionality most common platforms
have, it takes one (Unix) and wraps a thin layer around the standard C
library so it can be used in Ada."
Well it is POSIX specific rather than Unix specific, many non-Unix systems
have promised Posix compliance (including incidentally at one point OS/2).
Certainly for example NT provides POSIX compliance and so does VMS.
Yes, it is not necessarily portable to arbitrary non-POSIX compliant
environments but this discussion arose in the context of environment
variables, which are particular to Unix and Unix-like systems in any case.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Standard libraries (Was: Environment variables)
1996-11-16 0:00 ` Robert Dewar
@ 1996-11-17 0:00 ` Geert Bosch
1996-11-18 0:00 ` Larry Kilgallen
0 siblings, 1 reply; 39+ messages in thread
From: Geert Bosch @ 1996-11-17 0:00 UTC (permalink / raw)
Robert Dewar (dewar@merv.cs.nyu.edu) wrote:
"Well it is POSIX specific rather than Unix specific, many non-Unix
systems have promised Posix compliance (including incidentally at
one point OS/2). Certainly for example NT provides POSIX compliance
and so does VMS."
I wasn't saying that it is not possible to have a POSIX-layer
(I called it POSIX-emulation) on different platforms, just that the
abstraction used is not very usable. It is just backwards to use
very specific Unix calls which do not represent what you really want
to do and then have an emulation layer to translate the very specific
call to the more simple call that the underlying system provides.
For Ada it would be preferable to have simple extensions that use
the current standard library as a basis. Named pipes between processes
would be established by implementing a special File_Type that
can be be used as Ada.Streams.Root_Stream_Type'Class. There is a
reason that this is suggested in RM95 13.13(1). Certainly using the
Unix API standardized by POSIX is not EXACTLY the same.
Regards,
Geert
PS. It would be straightforward to port forest to OS/2, as much as it
is straightforward to post most Unix applications to OS/2.
--
E-Mail: geert@sun3.iaf.nl
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Standard libraries (Was: Environment variables)
1996-11-17 0:00 ` Geert Bosch
@ 1996-11-18 0:00 ` Larry Kilgallen
0 siblings, 0 replies; 39+ messages in thread
From: Larry Kilgallen @ 1996-11-18 0:00 UTC (permalink / raw)
In article <56n7p5$7co@fozzie.sun3.iaf.nl>, geert@fozzie.sun3.iaf.nl (Geert Bosch) writes:
> I wasn't saying that it is not possible to have a POSIX-layer
> (I called it POSIX-emulation) on different platforms, just that the
No, it really is POSIX -- a set of interfaces defined to be capable
of implementation on Unix and non-Unix systems alike.
> abstraction used is not very usable. It is just backwards to use
> very specific Unix calls which do not represent what you really want
> to do and then have an emulation layer to translate the very specific
> call to the more simple call that the underlying system provides.
If you look at the work various non-Unix vendors had to do to provide
POSIX support, you get an idea of the scope of effort required to get
"common" interfaces across operating systems. I am not personally a
fan of the POSIX interfaces, but at least it has a chance to be common.
> For Ada it would be preferable to have simple extensions that use
> the current standard library as a basis. Named pipes between processes
> would be established by implementing a special File_Type that
> can be be used as Ada.Streams.Root_Stream_Type'Class. There is a
> reason that this is suggested in RM95 13.13(1). Certainly using the
> Unix API standardized by POSIX is not EXACTLY the same.
For an Ada vendor to implement named pipes without support from the
OS vendor seems to me highly unlikely to be efficient, secure and
correct. I would prefer Ada implementors spent their time on the
quality of debugger support and interfaces to OS constructs which
are already well supported.
At some point, activities are just not portable. I have seen many
programs perform horribly after porting because someone neglected
the _fact_ that an operation which is quite efficient on one
operating system may well be horribly inefficient on another.
Larry Kilgallen
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Environment variables
1996-10-30 0:00 ` David Emery
` (4 preceding siblings ...)
1996-11-01 0:00 ` David Shochat
@ 1996-11-01 0:00 ` Stephen Leake
1996-11-02 0:00 ` Robert Dewar
1996-11-05 0:00 ` David Emery
6 siblings, 1 reply; 39+ messages in thread
From: Stephen Leake @ 1996-11-01 0:00 UTC (permalink / raw)
Laurent Guerby wrote:
>
> Robert> If you are using GNAT, take a look at GNAT.OS_Lib.Getenv in
> Robert> file g-os_lib.ads (there are lots of useful routines in this
> Robert> package :-)
>
> There's also Ada.Command_Line.Environment.
>
This package is in gnat, but it does not seem to be in the RM, at least,
not in the index or appendix A. Is it Ada 95 standard, or a gnat
extension? The source doesn't say either; do the sources of gnat
extensions indicate that they are extensions?
--
- Stephe
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Environment variables
1996-11-01 0:00 ` Environment variables Stephen Leake
@ 1996-11-02 0:00 ` Robert Dewar
1996-11-03 0:00 ` Robert A Duff
0 siblings, 1 reply; 39+ messages in thread
From: Robert Dewar @ 1996-11-02 0:00 UTC (permalink / raw)
iStephen asks
"This package is in gnat, but it does not seem to be in the RM, at least,
not in the index or appendix A. Is it Ada 95 standard, or a gnat
extension? The source doesn't say either; do the sources of gnat
extensions indicate that they are extensions?
This is not an extension to the language. Any Ada compiler can provide
additional useful packages
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Environment variables
1996-11-02 0:00 ` Robert Dewar
@ 1996-11-03 0:00 ` Robert A Duff
1996-11-03 0:00 ` Robert Dewar
1996-11-04 0:00 ` Tucker Taft
0 siblings, 2 replies; 39+ messages in thread
From: Robert A Duff @ 1996-11-03 0:00 UTC (permalink / raw)
In article <dewar.846951642@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>This is not an extension to the language. Any Ada compiler can provide
>additional useful packages
Robert, you have a strange definition of "extension". I would say: This
*is* an extension to the language. Any Ada compiler can provide
extensions of this nature (additional useful packages). Other
extensions that are explicitly allowed by the RM are additional pragmas
and attributes. Most extensions are of course DISallowed by the RM.
To the Ada programmer, this thing is an extension, in the sense that it
provides functionality available on GNAT, which may or may not be
available on some other compiler. In practical terms, if you use a
different compiler, your program will stop working.
- Bob
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Environment variables
1996-11-03 0:00 ` Robert A Duff
@ 1996-11-03 0:00 ` Robert Dewar
1996-11-04 0:00 ` Stephen Leake
1996-11-04 0:00 ` Tucker Taft
1 sibling, 1 reply; 39+ messages in thread
From: Robert Dewar @ 1996-11-03 0:00 UTC (permalink / raw)
Bob said
"Robert, you have a strange definition of "extension". I would say: This
*is* an extension to the language. Any Ada compiler can provide
extensions of this nature (additional useful packages). Other
extensions that are explicitly allowed by the RM are additional pragmas
and attributes. Most extensions are of course DISallowed by the RM.
To the Ada programmer, this thing is an extension, in the sense that it
provides functionality available on GNAT, which may or may not be
available on some other compiler. In practical terms, if you use a
different compiler, your program will stop working."
This is just a matter of terminology of course, but by your definition ANY
package provided with a compiler is an extension (there is nothing special
about calling a package Ada.xxxx.yyy from this point of view). I do not
find it useful to use the word extension in conjunction with packages (is
it an extension of C if you allow C programs to call sockets stuff?)
I would call additional pragmas and attributes cases of allowed extensions.
So, that's my definition. Additional packages that the compiler knows nothing
about but which are simply provided for use by users who want the facilities
in these packages I do not call extensions, additional pragmas or attributes
(or, getting into "non-permitted" areas) other language additions, I would
call extensions.
Sure, if you use packages that don't port, you are not portable, but the
distincition I make is a useful one. A package can be ported much more
easily than a pragma or attribute. It is true that a grandchild of
Ada is a little less portable, but it is easy to change its name.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Environment variables
1996-11-03 0:00 ` Robert Dewar
@ 1996-11-04 0:00 ` Stephen Leake
1996-11-04 0:00 ` Larry Kilgallen
1996-11-04 0:00 ` Robert Dewar
0 siblings, 2 replies; 39+ messages in thread
From: Stephen Leake @ 1996-11-04 0:00 UTC (permalink / raw)
Bob Duff wrote:
>
> "Robert, you have a strange definition of "extension". I would say: This
> *is* an extension to the language. Any Ada compiler can provide
> extensions of this nature (additional useful packages). Other
> extensions that are explicitly allowed by the RM are additional pragmas
> and attributes. Most extensions are of course DISallowed by the RM.
>
> [snip]
>
Robert Dewar wrote:
> This is just a matter of terminology of course, but by your definition ANY
> package provided with a compiler is an extension (there is nothing special
> about calling a package Ada.xxxx.yyy from this point of view). I do not
> find it useful to use the word extension in conjunction with packages (is
> it an extension of C if you allow C programs to call sockets stuff?)
>
> [snip]
As the one that started this thread (by asking whether
Ada.Command_Line.Environment was an `extension'), I'd like to say I
agree with Robert Dewar's definition of `extension'; I was being sloppy.
On the other hand, I think it would be reasonable to say that
Ada.Command_Line.Environment is an extension of the "Ada 95 Predefined
Language Environment", which is defined in Annex A of the RM; obviously,
any package could be described this way, so it's not a very useful
description.
In any case, as Laurent pointed, out, it IS possible to tell from the
sources that Ada.Command_Line.Environment is NOT defined by the Ada 95
RM, which is what I really wanted to know. However, it requires knowing
what the commenting style is in packages that are defined in the RM. I
think compiler-provided packages that are NOT defined by the RM should
be more clearly labeled as such, to make it easier to know when we are
being non-portable.
--
- Stephe
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Environment variables
1996-11-04 0:00 ` Stephen Leake
@ 1996-11-04 0:00 ` Larry Kilgallen
1996-11-04 0:00 ` Robert Dewar
1 sibling, 0 replies; 39+ messages in thread
From: Larry Kilgallen @ 1996-11-04 0:00 UTC (permalink / raw)
In article <327DF7F2.2484@gsfc.nasa.gov>, Stephen Leake <Stephen.Leake@gsfc.nasa.gov> writes:
> In any case, as Laurent pointed, out, it IS possible to tell from the
> sources that Ada.Command_Line.Environment is NOT defined by the Ada 95
> RM, which is what I really wanted to know. However, it requires knowing
> what the commenting style is in packages that are defined in the RM. I
> think compiler-provided packages that are NOT defined by the RM should
> be more clearly labeled as such, to make it easier to know when we are
> being non-portable.
Presumably most such packages would not be so intertwined as to require
that they be a child package of Ada.
Larry Kilgallen
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Environment variables
1996-11-04 0:00 ` Stephen Leake
1996-11-04 0:00 ` Larry Kilgallen
@ 1996-11-04 0:00 ` Robert Dewar
1 sibling, 0 replies; 39+ messages in thread
From: Robert Dewar @ 1996-11-04 0:00 UTC (permalink / raw)
Stephe said
"In any case, as Laurent pointed, out, it IS possible to tell from the
sources that Ada.Command_Line.Environment is NOT defined by the Ada 95
RM, which is what I really wanted to know. However, it requires knowing
what the commenting style is in packages that are defined in the RM. I
think compiler-provided packages that are NOT defined by the RM should
be more clearly labeled as such, to make it easier to know when we are
being non-portable."
Already done for the next release. Actually this was made a child package
of Ada.COmmand_Line with the thought of possible semi-standarization
(ACE?) in mind. Note that there is also a routine in GNAT.OS_Lib for
getting environment variables, which is more obviously a GNAT add on.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Environment variables
1996-11-03 0:00 ` Robert A Duff
1996-11-03 0:00 ` Robert Dewar
@ 1996-11-04 0:00 ` Tucker Taft
1 sibling, 0 replies; 39+ messages in thread
From: Tucker Taft @ 1996-11-04 0:00 UTC (permalink / raw)
Robert A Duff (bobduff@world.std.com) wrote:
: In article <dewar.846951642@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
: >This is not an extension to the language. Any Ada compiler can provide
: >additional useful packages
: Robert, you have a strange definition of "extension". I would say: This
: *is* an extension to the language. Any Ada compiler can provide
: extensions of this nature (additional useful packages). Other
: extensions that are explicitly allowed by the RM are additional pragmas
: and attributes. Most extensions are of course DISallowed by the RM.
: To the Ada programmer, this thing is an extension, in the sense that it
: provides functionality available on GNAT, which may or may not be
: available on some other compiler. In practical terms, if you use a
: different compiler, your program will stop working.
I think the big difference with this kind of extension is that
you can write such packages yourself, without having to talk to the
compiler vendor. On the other hand, other permissible "extensions"
like additional pragmas and attributes are almost always restricted
to the compiler implementor.
: - Bob
-Tucker Taft stt@inmet.com http://www.inmet.com/~stt/
Intermetrics, Inc. Cambridge, MA USA
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Environment variables
1996-10-30 0:00 ` David Emery
` (5 preceding siblings ...)
1996-11-01 0:00 ` Environment variables Stephen Leake
@ 1996-11-05 0:00 ` David Emery
6 siblings, 0 replies; 39+ messages in thread
From: David Emery @ 1996-11-05 0:00 UTC (permalink / raw)
Access to environment variables is included in POSIX/Ada
(ISO 14519-1:1995/IEEE 1003.5-1992), in the package
POSIX_Process_Environment.
dave
--
<.sig is away on vacation>
^ permalink raw reply [flat|nested] 39+ messages in thread