HDTenEightyP/NetNews huggingface dataset:
From: sss@nic.cerf.net (Marlene M. Eckert)
Newsgroups: comp.lang.ada
Subject: 'IMAGE
Date: 9 Apr 92 20:14:17 GMT
Followup-To: comp.lang.ada
Organization: 3S

Hello.

Should the following 'image of an uninitialized
enumeration type raise CONSTRAINT_ERROR?

In similar situations our compiler has printed all
blanks, garbage, and even readable garbage.  Of
course, the answer is probably in the LRM somewhere...

---------------------------------------------------------
with Text_IO; use Text_IO;
procedure Image is

type Colors is (Red, Green, Blue);

My_Color : Colors;  -- Not initialized!

begin

  Put_Line(Colors'image(My_Color)); -- Legal?

end Image;
---------------------------------------------------------

Thanks for the help.

------------------------------------------
Michael Reznick (We use a shared account.)
3S
sss@cerf.net
------------------------------------------
From: mfeldman@milton.u.washington.edu (Michael Feldman)
Newsgroups: comp.lang.ada
Subject: Access types and ALL
Date: 14 Apr 92 20:47:43 GMT
Reply-To: mfeldman@cs.washington.edu
Organization: University of Washington, Seattle

Given a record type 

  TYPE R IS RECORD
    ...
    F: Some_Type := Some_Value;
    ...

  END RECORD;

and an access type 

  TYPE R_Ptr IS ACCESS R;

  ...

  RP : R_Ptr := NEW R;

we can apparently select the field F in two ways:

  (1) RP.F

  (2) RP.ALL.F

Most examples in the literature use (1).

The LRM states that (1) is a basic operation of access types, and that
RP.ALL, which would normally be called a dereferencing operation, is
also a basic operation. In my travels through the LRM, though, I find
nothing saying that (1) and (2) are equivalent, though empirically they
seem to be so. Indeed, it seems that (1) can be seen as a kind of
shorthand for (2), in which the dot serves the dual role of dereferencing
and field selection. 

Yet the LRM suggests this only very indirectly (unless I've missed a key 
paragraph somewhere).

Question for language lawyers: is it correct to say that (1) and (2) are
at least informally equivalent? If not, are there non-pathological examples?

Thanks!

Mike Feldman
From: csa09@seq1.keele.ac.uk (P. Singleton)
Newsgroups: comp.lang.ada
Subject: Re: how pure are functions?
Date: 9 Apr 92 14:20:11 GMT
Organization: University of Keele, England

From article <18363@ector.cs.purdue.edu>, by young@cs.purdue.EDU (Michal Young):

> Mark Biggar says: 

>> More then likely that variable is only visible in the body of the package
>> that defines the function and so is invisible to the user of the function,
>> but strictly the function itself has no "internal" state. 
 
> This is true, strictly speaking, but from the viewpoint of a user,
> verifier, or compiler, Ada functions do not appear to be stateless.
> For instance, one cannot generally substitute 2*f(x) for f(x) + f(x).

Yes, that nicely exemplifies what I meant by "referential transparency",
which was: that the value of a function is determined *only* by its
arguments, and not by the history of execution, and so the compiler can
symbolically manipulate the program (e.g. transform it for efficiency, or
otherwise partially evaluate it, or reason about its correctness, etc.).
Also it should be free from side-effects (as well as the aforementioned
side-infects).

> There are good practical reasons for not insisting that every
> "function" be a pure function, but it would be quite helpful if the
> language provided some way to indicate that certain "functions" were
> actually functions in the mathematical sense.

Yes, I hoped that the distinction of "functions" from the honestly-named
"value-returning procedures", but I am told that this distinction is
obsolete.
----
  __   __    Paul Singleton (Mr)           JANET: paul@uk.ac.keele.cs
 |__) (__    Computer Science Dept.        other: paul@cs.keele.ac.uk
 |  .  __).  Keele University, Newcastle,    tel: +44 (0)782 621111 x7355
             Staffs ST5 5BG, ENGLAND         fax: +44 (0)782 713082
From: solomond@AJPO.SEI.CMU.EDU ("John P. Solomond, Director, AJPO")
Newsgroups: comp.lang.ada
Subject: AJPO Announcement - ACVC 1.11 Extended Life
Date: 14 Apr 92 14:58:44 GMT
Distribution: world
Organization: The Internet

------- Blind-Carbon-Copy

To: solomond
Subject: AJPO Announcement - ACVC 1.11 Extended Life
Date: Tue, 14 Apr 92 10:58:44 EDT
From: "John P. Solomond, Director, AJPO" <solomond>

			  AJPO ANNOUNCEMENT

ACVC 1.11 EXTENDED LIFE

In December 1990, I announced my intention to freeze the Ada Compiler
Validation Capability (ACVC) on version 1.11 for ANSI/MIL-STD
1815A (ISO/8652-1987 and FIPS 119, 1985).  During 1991, I have
heard arguments for and against issuing a "maintained"
version of ACVC 1.11. I have concluded that the original
"freeze" policy is in the best interest of Ada users, vendors
and the Ada 9X Project. 

Holders of current ACVC 1.11 certificates will soon receive a
replacement certificate from the AJPO which shows an expiration
date of ANSI/MIL-STD 1815B + 24 months.  This expiration "date"
means that the validated status of an ACVC 1.11 compiler will
be retained until two years after Ada 9X has been adopted by ANSI.
The ACVC version 1.11 will expire one year before certificates
(i.e., 12 months after ANSI Ada 9X adoption) as has been the practice.
This extended life for ACVC 1.11 means that there will be an
overlap period between ACVC 1.11 (for ANSI/MIL-STD 1815A validations)
and ACVC 2.0 (for ANSI/MIL-STD 1815B validations).  Some compiler
vendors may decide to skip ACVC 2.0 and put all their resources into
validating Ada 9X compilers with the more complete ACVC version 2.1.

A "freeze" on ACVC version 1.11 means that test programs may be
withdrawn but there will be no additions, modifications, or
re-issue of an ACVC version that measures conformity with
ANSI/MIL-STD 1815A.  The next ACVC version issued will be Ada 9X Basic
but it will be only for informational purposes. The Ada 9X Transition
Plan provides more information on the Ada 9X ACVC versions that will
be used to obtain Ada 9X validation certificates. 

I believe this policy provides benefits not only for Ada compiler
vendors but for users of Ada 83 compilers who can't wait for Ada 9X.
By reducing validation costs now, compiler vendors should
be able to fine-tune the performance of Ada 83 compilers and to provide
the robust tools that existing Ada projects need to cost-effectively
maintain applications.  I want to see software project managers make a
quick transition to the use of Ada 9X, but I also recognize that the
benefits of software engineering with Ada should not be postponed until
Ada 9X compilers are available.  I am counting on DoD software managers
to create a robust Ada market for high performance compilers and tools
for Ada 83 and for Ada 9X.  I am counting on Ada vendors to respond to
the relief from validation costs during this transition period with 
high quality conforming products. 


John P. Solomond
Director
Ada Joint Program Office
------- End of Blind-Carbon-Copy
Xref: sparky comp.lang.ada:1251 comp.unix.aix:5418
Newsgroups: comp.lang.ada,comp.unix.aix
Subject: Motif binding for IBM AIX Ada/6000 ?
From: srghdxp@grace.dsir.govt.nz
Date: 15 Apr 92 17:32:48 +1200
Organization: DSIR, Gracefield, New Zealand

Does anyone know of a Motif binding for IBM AIX Ada/6000 ?
I believe that this compiler is developed by Telesoft and that
Systems Engineering Research Corp are developing a Motif binding.
However I am interested in any comparative offerings from other
commercial/non-commercial sources.
Thanks  David Pairman, DSIR Physical Sciences, New Zealand
ph 64 4 5690281  fax 64 4 5690067
From: hayes%valkris@hac2arpa.hac.com (Brian Hayes 74-35 x65129)
Newsgroups: comp.lang.ada
Subject: Subprogram overloading
Date: 16 Apr 92 21:52:04 GMT
Organization: Hughes Aircraft Company; El Segundo, CA
Originator: hayes@valkris

Is it considered good form to overload basic io subprograms?
For example, I want to overload OPEN so I can print an error
containing the file name from my new OPEN subprogram when 
a file open error occurs.


I've just started teaching myself ada and I wrote my first 
program today ("hello world" =;^).  Just for the record
I've been programming in C (C for choatic) for the past two 
years and I'm looking forward to Ada programming.  From what 
little I've read, I can tell that I'll like it.  Ada seems 
to strike me as a software designer's/engineer's language; and 
C is ... well, lets say it's caused me enough headaches when
programming in team projects.  I think the only thing I might
miss is variable argument lists and the printf statement (
remember, I don;t know much about Ada).

Thanks in advance.



-- 
<<<<<<<<<< Brian Hayes hayes%bh_ddemo3@hac2arpa (310) 616-5129 >>>>>>>>>>>>
Newsgroups: comp.lang.ada
From: drew@sunrise.com (Drew Jenkins)
Subject: Are there any Ada Tech Journals?
Organization: Sunrise Software International
Date: Fri, 10 Apr 1992 20:17:49 GMT

I'm relatively new to the Ada programming environment and I was
wondering if there were any technical (or non-tech) journals
or magazines that are geared to the Ada community?


-- 
Drew Jenkins            "Attitude is Everything"
drew@sunrise.com                 -- Bingen Bart
From: byrne@ARECIBO.AERO.ORG ("DAN J. BYRNE")
Newsgroups: comp.lang.ada
Subject: Ada on HP RISC workstation
Date: 16 Apr 92 15:48:00 GMT
Distribution: world
Organization: The Internet


     I've been thinking of doing some work on a HP RISC
workstation but, I have a couple questions.  

     What Ada compilers are available for HP's new RISC
     workstations? 

     How much do they cost? 

     How good are they?  

     How mature are the compilers? 

     Does anyone have any advice about using Ada on HP's RISC
     machines?  

Thank You, in advance.  Dan Byrne

P. S.  The best address to send replies to is
byrne@arecibo.aero.org
From: deane@vaxc.cc.monash.edu.au
Newsgroups: comp.lang.ada
Subject: Ada/X/Motif multi-tasking
Date: 10 Apr 92 04:54:36 GMT


What are all of the problems associated with using Ada, X, and Motif ??
What solutions currently exist for these problems ????

I am currently involved in a project which requires use of Ada, X, and Motif.
The most important issue at this stage is portability across different
machines, operating systems, and Ada compilers. We wish to be able to use
the multi-tasking aspects of Ada.  The problems as I understand them are

1. The callback mechanism is not standard across compilers
2. Xlib routines are not re-entrant which means multiple Ada tasks cannot
   execute the routines simultaneously.
3. The standard event processing loop under Xt calls 'get-next-event'
   which suspends until the next event arrives.  This halts all Ada tasks
   within the process.
4. Widget inheritance and dynamic allocation of widget attributes is
   in conflict with Ada's strong typing model.

What other problems exist ?

The callback problem appears to be solved by using generics to hide
the details of the implementation.  How is this performed, and what
Ada compilers support this mechanism ?

The re-entrancy problem could be solved by using semaphores to control
multiple access.  What is the equivalent mechanism under Ada ?  Do any
of the Ada/X bindings supplied by compiler vendors solve this problem ?

The event processing can be re-written to poll events so that it never
suspends, or by using time-slicing with compilers that support it.  Both of
these constructs are not acceptable for our application due to response time
requirements.  We would prefer to avoid splitting the Ada tasks across
multiple Unix/VMS processes.  Is there a way to rewrite the event processing
so that it informs an Ada task when events have arrived ?  One way seems
to be to use Unix signals or VMS asynchronous traps combined with the Ada
rendevous.  Does anyone have any experience with this ?  What problems are
associated ?  I have seen a function under Telesoft Ada - TeleWindows which
appears to perform this but does not support multiple display connections.
Do other such routines exist under other Ada/X/Xt/Motif bindings for other
compilers ?  Could these routines be written using Posix bindings ?

What reasonably clean solutions exist for combining the X-window paradigm
(event driven, callbacks, inheritance, dynamic configuration etc) with
the Ada object oriented paradigm (tasking, generics, strong typing etc) ?
How can new widgets be written in Ada ?

Finally, does anybody know anything about X11R6 which supposedly will support
multi-threaded processes ?
Newsgroups: comp.lang.ada
From: vanderwerkend@lonexc.rl.af.mil (Dan Vanderwerken)
Subject: Re: Open comment to Ted Holden
Organization: RADC
Date: Fri, 10 Apr 92 17:08:59 GMT

In article <SRCTRAN.92Apr9102404@world.std.com> srctran@world.std.com (Gregory Aharonian) writes:
>Sam,
[stuff about Ada not being cost effective deleted....]
>A good number of soldiers ordered commercial,
>off-the-shelf GPS recievers with their credit cards during the Gulf War,
>and had no complaints about their operations, especially those whose lives
>were saved.  If commercial, off-the-shelf, less mil-spec equipement passed
>the test of combat, maybe the DoD software standards are as excessive. 
>Greg Aharonian
>Source Translation & Optimization

This thread certainly looks like it will provide lively discussion for this
group...I'd like to throw in my two cents too:

As far as Ada being cost effective--you need to look at the bigger picture.
We don't just _develop_ weapon systems.  We deploy, use, and _maintain_ them.
One of the bigger (and cost effective) advantages of Ada is it ease of 
maintainability.  Instead of giving some contractor one hundred thousand
lines of spegetti code in C, we give them Ada.  Now, I don't tremendous personal
experiance saying Ada is better to maintain, but everything I've dealt with
does strongly suggest this is the case.  Just for the record, I'm fairly
certain the maintenance costs of our weapon systems far exceed the development
costs.  This _is_ something to think about.

Using the GPS receiver analogy is somewhat inaccurate (IMHO).  It's paramount
to saying that smoking isn't bad for your health because you have a ninety
year old grandfather who still smokes (while the other ninety percent of
all smokers have already died of smoking related illnesses).  We build our
weapon systems to _survive_ a war time environment.  If the commercial GPS
receivers worked, great, but that performance doesn't guarantee they'll work
under all specified conditions.  

During the Gulf War, we had a four star general come and explain how everyone 
laughed at the Air Force's requirement for a FAX machine which worked in 
seemingly rediculous temperature extremes.  He then explained how those very 
same FAX machines were presently working in the desert under those extreme 
temperature conditions...and working well while other FAX machines (commercial)
had crapped out.

Ada software development is just the beginning of a weapon system's life
cycle.  Ada _may_ be more expensive to program in now, but I suspect it will
get less expensive as more and more companies begin to use it.  It's the
long-term life cycle maintenance where Ada will really pay off.  We're still
maintaining systems built with FORTRAN and assembly code almost twenty years
ago.

---Dan---

-- 
+ Captain Daniel F. Van Der Werken, Jr., USAF |  I do not speak for the Air
+ Rome Laboratory/OCDS                        |  Force, otherwise I'll be
+ Griffiss AFB, NY 13441                      |  in Kansas making big rocks
+ (315) 330-4441/DSN 587-4441                 |  into little rocks!
Newsgroups: comp.lang.ada,comp.realtime,comp.object
From: karam@sce.carleton.ca (Gerald Karam)
Subject: REPOST: TimeBench Binary available by Anon. FTP
Organization: Carleton University
Date: Sat, 11 Apr 1992 14:53:16 GMT

TimeBench is a CAD tool for the design of real-time systems. Its main
features include:

 1. a hybrid graphical/textual design description notation.
 2. design experimentation through an embedded design interpreter and
    behaviour visualization techniques.
 3. a performance analysis tool.
 4. a code generation systems for Ada and C/JNX target environments
    (JNX is a real-time kernel for PCs).

TimeBench Supports an extended version of Buhr's diagramming notation
called "MachineCharts".

The binary version is available by anonymous FTP from ftp.sce.carleton.ca
(address 134.117.4.42). To get the software please "cd pub/timebench"

When logging in as "anonymous" please use your email address as the
password.

Environment: SUN SPARC/SUN-3 workstations running Sun OS 4.1.1.  It uses
             SunView but should work under OpenLook as well.  Colour
             workstations are also supported.

If you transfer any files from this directory, please send a mail
message to karam@sce.carleton.ca.  This will enable us to notify you
of new revisions, bug fixes.  For further information or help contact
"timebench-help@sce.carleton.ca"

Please let us know how you are using the software.



--
Gerald Karam           |"Underachiever, and proud of it, man!" - Bart Simpson
karam@sce.carleton.ca  |"Don't have a cow, man!" - Bart Simpson
Fax: +1 613 788 5727   |"Be cool, dude" - Bart Simpson (Bartman)
Ph:  +1 613 788 5749   |"Don't call me dude!" - anonymous
From: williams8572@iscsvax.uni.edu
Newsgroups: comp.lang.ada
Subject: new
Date: 8 Apr 92 18:05:59 -0500
Organization: University of Northern Iowa

hello,
   I took a year of ada as a freshaman and fell in love with it, but I have
not been able to use it since due to lack of a good compiler.  What compilers
do you guys reccomend.  Any available via anon ftp?

-- 

******lid11 - Black Industrial Diamonds demo.  Reply to me if interested.******
-------------------------------------------------------------------------------
                               from the desk of  
                        
        Robert A. Williams, social deviant, driller killer ripping holes
-------------------------------------------------------------------------------
From: dappel@grafted.UUCP (Dave Appel)
Newsgroups: comp.lang.ada
Subject: Re: Open comment to Ted Holden
Date: 15 Apr 92 04:33:04 GMT
Organization: GRAFTED, Central Indiana's Usenet BBS 317-881-4369

news@fedfil.UUCP (news) writes:
> Several points:  The commercial software venders are now adhering
> to standards, the most serious from the perspective of languages 
> being C/C++.  The argument you give would pertain in a situation
> in which Borland, MicroSoft, Ashton-Tate et. al. were each hawking
> their very own language.  The reality is quite different.  The choice
> is between the standard North American programming language (C/C++)
> which everybody uses and which is well understood by most serious
> programmers, and the flakey piece of garbage known as Ada.
> 
> The problems mentioned in that large post of mine are real enough.  Some
> very bright people have been wasting their lives spending 12 hours working
> around Ada and one hour solving their own problem (to the extent
> possible WITH Ada)..
> 
> Virtually all really vital and serious military work is still being
> done in C and other languages with waivers.  There's a real reason
> for that.
> 
> Ted Holden
> -- 
> HTE
> bear

   I hate to burst your bubble Ted, but "everbody" doesn't
use C/C++.
    Most business systems (counting systems or packages, not
installations) are written in COBOL.  There is still more
lines of COBOL "in production" than any other language in
the business environment.
    Most scientific stuff is still in Fortran.  I did a survey
in comp.sys.super and by FAR the largest amount of production
code and by FAR the largest amount of development is in
Fortran when dealing with supercomputers.  I talked to people
involved in NCSA and they say Fortran is by far and away the
language of choice on supers.
 
Also, there is no "Standard C".   Ansi C and K&R C are *NOT*
"standards" that are adhered to.  Talk to the people at
Aldus corporation, the people who wrote PageMaker.  They
have PageMaker on the Mac and PageMaker on the PC.  Only 
about 80% of the code is identical between the two systems.
 
Graphic handling and system calls are still too different.
 
I went over this "C is not C all around the world" with a friend
of mine when we discussed writing a business program in C.
 
I wanted a C program that was portable to mini-computers and
workstations.  He wanted to write it in Borland C with
Borland's user interface package.   I can think of 3 
completely different versions of the package:
  1) character based version for minicomputer users running
      dumb terminals
  2) X-windows based version for workstations
  3) PC-based version with Brand-X user interace package.

--
Dave Appel
The Grafted Branch BBS
317-881-4369
internet: dappel@grafted.UUCP
uucp: ..!uunet!grafted.UUCP!dappel
 = = Grafted Branch BBS (317) 889-6997 2 Gig on-line = =
From: mfausett@bbn.com (Mark Fausett)
Newsgroups: comp.lang.ada
Subject: Re: Open comment to Ted Holden
Date: 16 Apr 92 16:55:02 GMT
NNTP-Posting-Host: kirin.bbn.com

wicklund@intellistor.com (Tom Wicklund) writes:

MISC DELETED HERE

>A negative is that an absolute Ada requirement restricts the use of
>new technology.  For example, there are Ada versions of Lex and Yacc.
>Unfortunately, in a military contract the deliverable would have to be
>the Ada output of Lex and Yacc (very unmaintainable tables) rather
>than the maintainable Lex and Yacc source (since it isn't Ada source).
>To the extent this forces programmers to avoid such tools, Ada may
>promote the use of less reliable code by requiring less clear
>expression of the ideas desired.

Sigh...  Once upon a time I had an argument with a contract manager at
Rome Lab who was sponsoring some R&D on AI/Distributed systems.  His contractor
wanted to use a system which compiled a high-level AI'ish
language into an intermediate language (in this case C) which was then compiled
into object.  The manager wanted the contractor to make his system generate
Ada as the intermediate code so that the system would be more maintainable(!),
understandable, etc., (and of course, so it would meet the "letter of the 
law".  There was no argument that the production language was more 
appropriate than raw Ada for the particular problem, BUT he clung to this 
mystical belief that in the mere presence of Ada somewhere in the 
system would have the magical effect of somehow making the system more 
understandable/maintainable/etc.

I think that this view of Ada as a panacea is what most disturbs me most.
In fact, some of my instructors at the military schools I attended seemed to
belive that Ada alone was enough to guarantee good, maintainable, well designed
programs.  (Why is it that some people persist in believing in Magic?)
(No Grady, you were not one of them :^)

MORE DELETED HERE

>sure it's inherently safer than other languages, my experience is that
>the quality of the people producing a product matters more than the
>language used to implement it.  Ada may include exception handling,
>but this doesn't matter if the programmer doesn't handle the exception

Hear Hear!
Ada does have more safety checks that most other languages and attempts to
restrict "dangerous" programming practices;  Still, never doubt the ingenuity
of people who are intent on overcoming these "limitations".  I've seen 
programmers build dynamically bound object systems in Ada through generous
use of unchecked type conversion...:^)

Mark Fausett
From: AUTOPVA@FRFUPL11.BITNET (Philippe Vanheeghe)
Newsgroups: comp.lang.ada
Subject: Ada LIbrary
Date: 6 Apr 92 23:18:31 GMT
Organization: The Internet


 
 
please,
Could you tell me if i can find the librairies SLINPACK, DLINPACK and
EISPACK for the Ada programming language.
 
            Thank You.
                  P.Vanheeghe