HDTenEightyP/NetNews huggingface dataset:
From: adainfo@AJPO.SEI.CMU.EDU ("Ada Information Clearinghouse")
Newsgroups: comp.lang.ada
Subject: Ada 9X Receives International Go-Ahead
Date: 6 Apr 92 20:05:13 GMT
Organization: The Internet


             Ada 9X Receives International Go-Ahead

The revision of the international Ada programming language
standard, know as Ada 9X, was the topic of discussion at a
multinational working group meeting of software experts held in
Frankfurt, Germany, March 30-April 3, 1992, under the auspices of
the International Organization for Standardization (ISO).  Ada is
widely recognized as the programming language-of-choice for
software engineering in a wide range of applications that require
an engineered solution.  

In addition to broadening the application domain of Ada, e.g.,
information systems, and to improving support for new paradigms
like object-oriented programming (OOP), the proposed changes are
expected to further enhance the support to software engineering in
programming reliable, efficient, and maintainable software.

After extensive deliberations and formal voting, delegations from
12 countries approved the proposed baseline for language changes
and granted permission to proceed to the next phase of translating
these changes to revised working in the language reference manual
that defines the standard.  Participating countries included
Belgium, Canada, France, Germany, Japan, the Netherlands, Russia,
Spain, Sweden, Switzerland, the United Kingdom, and the United
States.

The chairman of the working group, Dr. Robert Mathis (USA), stated
that "the meeting resulted in reaching a major milestone in the Ada
revision process and the delegates sent a strong signal to the Ada
9X Project Office (USA that directs the process that the
international community is solidly behind its activities."  the Ada
9X Project Manager, Christine Anderson, felt that this level of
consensus was what the Ada 9X team had been working toward since
1988.  Anderson said, "It was a very welcome and essential
message."

----------------------------------------------------------------------
This article is being posted for the Ada 9X Project Office.
Newsgroups: comp.lang.ada
Subject: Software Engineering Position,  Dayton OH
From: mtabacch@eve.wright.edu (Marci Tabacchi)
Date: 6 Apr 92 14:39:14 EST
Organization: Wright State University


I know this is not the right place, but thought it
would be a good place.




Ada Software Development Position


Science Applications International Corporation has
a need for a Software Engineer to do Ada/X/Object Oriented
design and development for a large scale project.


Aspects of this position:

	1. Permanent position.
	2. Object-Oriented design.
	3. Ada & X Window System.
	4. Good growth potential in well established company.

 
Please call Larry Janning @ 
		513-429-6500 

or fax your resume to
		513-429-6500

or send your resume to 

		Larry Janning
		1321 Research Park Drive
		Dayton, Oh  45432
From: csa09@seq1.keele.ac.uk (P. Singleton)
Newsgroups: comp.lang.ada
Subject: how pure are functions?
Keywords: referential transparency
Date: 7 Apr 92 10:46:13 GMT
Organization: University of Keele, England

Sorry I don't follow this group, but I heard that Ada distinguishes
"functions" from "value-returning procedures".  Are "functions"
prohibited from accessing or altering global variables?  Are they
free from internal state?  Are they "functions" in the mathematical
sense?  Are their calls referentially transparent?  Does anyone care?!
---
  __   __    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
Newsgroups: comp.lang.ada
From: wicklund@intellistor.com (Tom Wicklund)
Subject: Re: Open comment to Ted Holden
Organization: Intellistor, Inc.
Date: Wed, 15 Apr 92 01:12:00 GMT

A few thoughts on this thread after reading some of the Ada 9X
material and seeing several of the "Ada vs C/C++/whatever"
discussions.

First, Ada has one important function for Dod -- eliminating the
hundreds of languages which used to be used for software development.
From this standpoint it's very cost effective and very necessary.

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.


I find that the core of Ada is a reasonable language to use.  I'm not
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
or handles it poorly.  What is needed (and beyond current technology)
is tools to verify that things like exception cases have been dealt
with.  Ada doesn't assist in this area though some features of Ada may
assist in static or dynamic analysis of a program.


My biggest problem with Ada is its attempt to sort of be an operating
system.  The inclusion of tasking and exceptions in the language makes
it hard to implement Ada on top of languages which use a different
tasking or exception model.  This is seen by Ada 9X, which greatly
expands the tasking / exception related features (including a couple
cases of doing the same thing in two ways and an example of a backdoor
use of a feature which rates up with the worst of spaghetti code).

This combines with an attempt at ultra portability -- zero changes to
an Ada program when porting between environments -- which means that
with time there will be pressure to add  more and more operating
system features to Ada so that software can be portable.  While most
of the need for Ada's operating system features is embedded systems
(which often don't have an operating system running), part of the push
for ultra portability seems to be from operating system hosted
application programs.
From: mfausett@bbn.com (Mark Fausett)
Newsgroups: comp.lang.ada
Subject: Re: Open comment to Ted Holden
Date: 16 Apr 92 17:27:39 GMT
NNTP-Posting-Host: kirin.bbn.com

dappel@grafted.UUCP (Dave Appel) writes:

>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.
> 
So,
How does Ada solve this problem;  should the language become the OS?
Wouldn't an Ada version of PageMaker differ between platforms as well?


Mark Fausett
mfausett@bbn.com
From: mfausett@bbn.com (Mark Fausett)
Newsgroups: comp.lang.ada
Subject: Re: Open comment to Ted Holden
Date: 13 Apr 92 17:28:26 GMT
NNTP-Posting-Host: kirin.bbn.com

vanderwerkend@lonexc.rl.af.mil (Dan Vanderwerken) writes:

>In article <SRCTRAN.92Apr9102404@world.std.com> srctran@world.std.com (Gregory Aharonian) writes:
>>Sam,
>[stuff about Ada not being cost effective deleted....]

>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

Funny, I've seen lots of spaghetti code writting in almost every language,
including Ada.  Good program design and implementation are much more an 
attribute of the programmer than the implementation language.

>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.

Absolutely; the bulk of the cost, expecially in military systems is in
maintenance, especially since the military never seems to throw anything away.
In fact, I remember rumors of the USAF negotiating a contract for 20 years of
maintenance on a Honeywell DPS-8 running GCOS, when GCOS was already 10 years
obsolete.

Still, I'd be willing to bet that a well-designed and written software system
in any language will be easier to maintain than a poorly designed and written
system in Ada.

While standardization may be desirable sometimes, we also have to remember that
computer langauges are TOOLS for expressing ideas in the form of programs.
Computer languages aren't usually created for the intellectual joy of creation
but rather to solve particular kinds of problems;  Thus some languages 
will be more effective at solving particular problems than others.  If you
doubt this, compare the difficulty of writing a heuristic search program in
LISP and {Ada, C, C++} etc., or an OS kernel in C versus {Ada, COBOL, etc.}.

It seems to me that the least-cost solution to solving a problem is to carefully
engineer the design, choose the right tools (language, development environment,
execution environment) for the job, and properly execute the design.
The only major drawback that I see is that maintenance programmers might be
forced to learn more than one computer language; something which a lot of people
seem to be inordinately afraid of.

Mark Fausett
mfausett@bbn.com
Newsgroups: comp.lang.ada
From: spray@convex.com (Rob Spray)
Subject: Re: Open comment to Ted Holden
Organization: CONVEX Computer Corporation, Richardson, Tx., USA
Date: Thu, 9 Apr 1992 17:40:53 GMT
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

In <1992Apr9.155334.20536@schaefer.math.wisc.edu> nedervol@schaefer.math.wisc.edu (Eric Nedervold) writes:

>Does this argument extend to hardware too?  Like $500 toilet seats?

I believe that most of these popular DoD-bashing anecdotes are driven
by:

a) Poor or overlooked requirements specifications that cause things
   like expensive coffee pots because all equipment on a certain
   aircraft has some blanket requirement that it be radiation-hardened
   or will continue to operate if the aircraft is inverted!

b) The result of cost-recovery by contractors driven by the current
   government procurement practises that almost preclude accurately
   costed proposals from winning contracts.

c) Blanket requirements for specifications and documentation, that,
   for example, drive up the procured cost of what the "general
   public" could buy commercially.

I think it is specious to introduce hot button phrases like
"$500 toilet seats" into some people's attempts at a rational
discussion on software technology transfer.

--Rob   spray@convex.com

Flaming for myself.

Newsgroups: comp.lang.ada
From: consp10@bingsunb.cc.binghamton.edu (Julian Insan Kamil)
Subject: associate functions to objects
Keywords: function, object
Organization: State University of New York at Binghamton
Date: Tue, 14 Apr 1992 05:21:37 GMT

I'm working on a project for a Software Engineering class, and we're using Ada to
develop a simple database management application. My part is on building the user
interface for the app. One of the data type that we're using is called an
EntryBoard which is supposed to manage a list of other objects like Fields,
Buttons, Titles, etc. Each of those objects should be attached to a function that
will be called whenever that object is selected (sort of like callback
functions). Now, how do you attach functions to objects? I consulted my Ada
references and it seems that Ada doesn't allow passing functions as a parameter
to a procedure (the way I did it in C++ to implement the same behavior). I need
hints and advice and examples on how to do this kind of things. Will anybody help
me with some light? 

-Julian Insan Kamil
Computer Consultant at SUNY-Binghamton
email: consp10@bingsunb.cc.binghamton.edu
email: consp10@bingvaxu.cc.binghamton.edu
From: rcs00455@zach.fit.edu (Kevin Anderson / Lazlo)
Newsgroups: comp.lang.ada
Subject: Questions about use of Ada in Real-Time Systems.
Date: 16 Apr 92 18:48:15 GMT
Distribution: usa
Organization: Florida Institute of Technology, Melbourne USA

I have some questions concerning the current use of Ada in real-time
systems.  They are for some research I am doing here at school.

1) What do you find are the main problems of using Ada in implementing
   real-time systems?

2) What aspects of real-time systems are you able to implement within
   the Ada language?

3) What aspects of real-time systems do you have to "go outside the
   language" or use "work-arounds" to implement?  Why?

4) What types of work-arounds do you usually use when implementing
   real-time systems in Ada?

Feel free to give specific examples in answering any of the questions.
Any help would be appreciated.  Please respond by e-mail, I will post
a summary if I get any requests for one.

Kevin Anderson
kevin@se.cs.fit.edu
rcs00455@zach.fit.edu
From: koehnema@enuxha.eas.asu.edu (Harry Koehnemann)
Newsgroups: comp.lang.ada
Subject: Re: Open comment to Ted Holden
Date: 13 Apr 92 21:34:58 GMT
Reply-To: koehnema@enuxha.eas.asu.edu (Harry Koehnemann)
Followup-To: comp.lang.ada
Organization: Arizona State University

In article <mfausett.703186106@kirin> mfausett@bbn.com (Mark Fausett) writes:
>
>Funny, I've seen lots of spaghetti code writting in almost every language,
>including Ada.  Good program design and implementation are much more an 
>attribute of the programmer than the implementation language.

It's also an attribute of managerial pressures and marketing idiots.
This, perhaps as much as anything, leads to poor quality code.  Many of
the short cuts you can take in other languages don't exist in Ada
(privates, packaging, and particularly the typing mechanism) so that
such pressures don't propogate themselves into the code as easily as
they can with C and other languages.
--
Harry Koehnemann
koehnema@enuxha.eas.asu.edu
Newsgroups: comp.lang.ada
From: VALLHON@ricevm1.rice.edu (VALLHONRAT, S V)
Subject: Object-Oriented Design Course offered
Organization: Rice University, Houston, TX
Date: Thu, 9 Apr 1992 15:38:31 GMT

Rice University's Office of Continuing Studies is offering a three day
course, "Object-Oriented Analysis, Modeling, and Design," on June 1-3, 1992
in Houston, Texas. The fee for this course is $595.  For more information,
please call (713) 527-4803 or (713) 520-6022.
From: wicklund@intellistor.com (Tom Wicklund)
Newsgroups: comp.lang.ada
Subject: Re: Open comment to Ted Holden
Date: 15 Apr 92 15:17:00 GMT
Organization: Intellistor, Inc.

In <TD79iB1w161w@grafted.UUCP> dappel@grafted.UUCP (Dave Appel) writes:

>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.

But Standard C doesn't define a graphical interface.  An Ada version
of the PageMaker would also only have about 80% of the code common
because the system calls would still differ.  Smart design can isolate
these differences and make them easy to maintain.

The only way to make code 100% portable will be to combine the
operating system and language into one standard.  Ada sometimes tries
to do this but so far other than tasking / distributed systems
features seems to be remaining a programming language.
Newsgroups: comp.lang.ada
From: jordan@aero.org (Larry M. Jordan)
Subject: Re: Ada vs. C++ Paper (was Re: Why ADA?)
Organization: The Aerospace Corporation
Date: Fri, 17 Apr 1992 16:31:40 GMT


>Possibly the strongest conclusion in the paper is that the inheritance
>feature in C++ is extremely tricky to use, and can lead to big time problems.
>I asked him if he still feels this way, and he said he does, more so
>even than before. ...

Anyone care to enumerate some of these so called "big time problems"? 
Is the problem with inheritance in general (is Eiffel subject to these
same problems?  Turbo Pascal 5.5+?) or with inheritance coupled with
dynamic binding?

Does the paper talk at all about C++'s lack of "packages"?  This strikes
me as a much bigger problem than "inheritance".

--Larry %)
Newsgroups: comp.lang.ada
From: bhanafee@deimos.ads.com (Brian Hanafee)
Subject: Re: 'IMAGE
Followup-To: comp.lang.ada
Organization: Advanced Decision Systems, Mountain View, CA 94043, +1 (415)
	960-7300
Date: Thu, 9 Apr 1992 22:00:43 GMT


In article <1714@nic.cerf.net> sss@nic.cerf.net (Marlene M. Eckert) writes:
>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...
[example code deleted]

Yes, the answer is in the LRM, in 3.2.1/18:

"...The execution of a program is erroneous if it attempts to evaluate a
scalar variable with an undefined value..."

Your program is erroneous.  What does that mean?  Once again, the
LRM has the answer, in 1.6 (c):

"(c)  Erroneous execution. 

     The language rules specify certain rules to be obeyed by Ada programs,
     although  there is no requirement on Ada compilers to provide either a
     compilation-time or a run-time detection  of  the  violation  of  such
     rules.   The  errors  of this category are indicated by the use of the
     word  erroneous  to  qualify  the  execution  of   the   corresponding
     constructs.  The effect of erroneous execution is unpredictable."

Thus, the behavior of your program is, as you have already observed,
unpredictable.


--
Brian Hanafee                         Advanced Decision Systems
bhanafee@ads.com                      1500 Plymouth Street
(415) 960-7300                        Mountain View, CA 94043-1230
Newsgroups: comp.lang.ada
From: eachus@Dr_No.mitre.org (Robert I. Eachus)
Subject: Re: General task pointers, messages
Organization: The Mitre Corp., Bedford, MA.
Date: Wed, 8 Apr 1992 22:02:16 GMT

In article <1992Apr3.230532.6704@mack.uit.no> roarf@stud.cs.uit.no (Roar Foshaug) writes:

   I have two questions concerning tasks and synchronization of tasks. I 
   work on parallell simulation in Ada, and need Ada tasks to communicate
   in a two-way fashion...

   The usual way to do this in Ada is to use two calls and have the
task structure such that the return message always goes to the "right"
task:

      task X is				task Y is
      ...				  entry Request_Service(...);
      end X;				  entry Return_Status(...);
					end Y;

      task body X is			task body Y is
      begin				begin
        Y.Request_Service(...);		  loop
        ...				    accept Request_Service(...);
        Y.Return_Status(...);		    ...
	...				    accept Return_Status(...);
      end X;				  end loop;
					end Y;

     Note that X can use a conditional entry call on Return_Status to
avoid waiting on Y, but task Y can be tied up waiting for X to get its
status.  To avoid this problem you can use entry families to allow Y
to serve multiple requests, however the code gets messy so I won't
include it here.  (Declare Return_Status as an entry family, and pass
the index as an out parameter of the call to Request_Service.)


   The other question is whether it is possible to send asynchronous
   messages between tasks?  I would like a task to be able to tell
   another task something without blocking...

    There is a way to do it using pragma SHARED.  If you want to send
more than a word of data it is technically erroneous although most Ada
implementations implement it correctly.  However, if you are using
multiple processors with caches, you may have to explicitly code a
cache flush operation.

--

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...
From: kmsimons@cs.utah.edu (Kevin Simonson)
Newsgroups: comp.lang.ada
Subject: integer'image versus integer_io
Summary: Why use integer_io in output mixed with text?
Date: 13 Apr 92 17:31:49 GMT
Article-I.D.: hellgate.1992Apr13.113149.20126
Organization: University of Utah CS Dept
Originator: kmsimons@cs.utah.edu


     If I want to output an integer to standard output, or to a file, I can
do it either by instantiating the generic package "integer_io", or by using
the "integer'image" attribute.  Therefore the following code gives me iden-
tical results:

   package IIO is new text_io.integer_io (integer);
   II : integer;

   text_io.put ("Enter value:  ");
   IIO.get (II);
   text_io.put ("Value entered is [");
   IIO.put (II, 1);
   text_io.put_line ("].");

                         versus

   package IIO is new text_io.integer_io (integer);
   II : integer;

   text_io.put ("Enter value:  ");
   IIO.get (II);
   text_io.put_line ("Value entered is [" & integer'image (II) & "].");

     The only difference I get from my compiler is that with the "'image"
version there's an extra space in front of the integer for a sign value.

     My question is, if you want to output integers mixed with text, and if
you don't mind about that first position for the sign, is there really any
reason to use an "integer_io" instantiation over just using
"integer'image"?

     It seems like the "'image" version would be more effective, too, since
in the other version I'd have to use three I/O calls, versus the one I/O
call for the concatentated string.

     If anybody knows any reason why concatenating "integer'image" might
cause me any grief, please let me know.  Respond by e-mail if you can; it
takes forever for these articles to get to my network.  Thanks.

                                     ---Kevin Simonson
From: SAHARBAUGH@ROO.FIT.EDU
Newsgroups: comp.lang.ada
Subject: Open comment to Ted Holden
Date: 8 Apr 92 13:56:00 GMT
Organization: The Internet

Ted,
  You do not seem to grasp the difference between the mission of
the US Army and the mission of commercial software vendors.
The US Army must defend our country and keep you and I and
our decendants safe.  The commercial software vendors must
make a profit for their stockholders.
  You do not seem to grasp the difference in performance
requirements ofr military software vs commercial software.
Military software must work or we may lose the war.  I urge
you to talk to some survivors from countries who lost wars.
Theirs is not a pleasant story, and they were the survivors.
Commercial software must only work well enough so that someone
will buy it and continue to buy the upgrades. I personally
call commercial software "crap for brains".  I have examples
to back that up.
  No matter what Army software costs it is cheaper than the
alternative.  Imagine an enemy with Apache helicopter
equivalents in your home town for an hour. The national
debt may be huge but it is not as huge as the cost of
rebuilding Wash DC or New Yoork after a nuclear attack.
And, as an extra added benefit, we are alive and well
and our infrastructure is intact and we can work to
pay off that debt.
  I agree with NOTHING you say but I defend your right
to say it.
sam harbaugh saharbaugh@ROO.FIT.EDU        
-----------
ps: pls excuse the typos
---
Newsgroups: comp.lang.ada