HDTenEightyP/NetNews huggingface dataset:
From: koehnema@enuxha.eas.asu.edu (Harry Koehnemann)
Newsgroups: comp.lang.ada
Subject: Re: Ada vs. C++ Paper (was Re: Why ADA?)
Date: 17 Apr 92 17:09:25 GMT
Reply-To: koehnema@enuxha.eas.asu.edu (Harry Koehnemann)
Followup-To: comp.lang.ada
Organization: Arizona State University

In article <1992Apr17.163140.17331@aero.org> jordan@aero.org (Larry M. Jordan) writes:
>>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?

One problem with C++'s inheritance is naming conflicts.  If an operation
is given by a parent and a grandparent have the same name, the user must
explicitly name the grandparent in the call if they wish to invoke that
operation.  This completely violates the infoirmation hiding OO was
supposed to provide us.  What happens when we redesign that parent/
grandparent - all the users of that class must be rewritten.  No, Eiffel
does not suffer from this problem (a name can only propagate out of a
class with one meaning).  You use the renames construct to change the
name you're exporting - don't know about TPascal.

It seems that the real problem is that no one has done a real good job
completely defining the semantics of inheritance.  Eiffel didn't get this
correct in its early versions either and the last Eiffel compiler (they
have new versions almost bi-annually) I used completely fell apart when
multiple inheritance was brought into the picture (internal compiler
errors when renaming with multiple inheritance).
--
Harry Koehnemann
koehnema@enuxha.eas.asu.edu
Newsgroups: comp.lang.ada
From: emery@Dr_No.mitre.org (David Emery)
Subject: Re: <none>
Organization: The Mitre Corp., Bedford, MA.
Date: Fri, 3 Apr 1992 15:57:45 GMT

>Marci Khader says
>In 'C' you could do a fork with the parent not waiting for the
>child to finish.  

You can just as easily do this in Ada.  But, you'll pay all of the
substantial costs for _process_ context switching in Unix (or VMS).
This cost tends to be prohibitive for many applications!

				dave
Newsgroups: comp.lang.ada
From: jgg@widget!uunet.uu.net (Xmiester)
Subject: Re: Ada multitasking with X-windows
Organization: EVB Software Engineering
Date: Sun, 12 Apr 1992 18:19:02 GMT


dwb@IMD.Sterling.COM (David Boyd) writes:

[... read earilier news posts on comp.windows.x to get the preliminaries ...]

>
>	And the government wants to know why developing X applications
>in Ada costs so much!!  
>
Compared to what?  Who has been doing this complaining?  I've been
searching for this information, but have yet been able to find any.

>I am old enough to remember the tail end of JOVIAL
>(a previous government developed language) and someone asking us to develop
>bindings between our FORTRAN libraries and JOVIAL.  The problems were very
>similar and the solutions equally ugly in many cases and JOVIAL was not as
>different from FORTRAN as Ada is from C.  
>

The currently available commercial Ada/Motif bindings can hardly be
called ugly.  They are as clean (or cleaner) than the C interface
with stronger type checking.  (Can you say "pragma External" ?)

>
>	The solution is for someone to
>completely re-implement not only the X library and intrinsics with a
>design geared toward Ada but the GUIs libraries (OLIT & MOTIF) as well.
>

I hardly believe this is a cost effective solution.  The answer is *NOT*
to re-invent a *better* wheel w/o a justification for the cost.  The
majority of Ada projects can deal with non-reentrant X/Xt/Motif libs.
It just requires knowledge and good design to do it right.  I suggest
that a better spent dollar is in the training of Ada engineers on the
issues and how to deal with them effectively from an engineering standpoint.
(It's surprising how many Ada programmer's I meet who write multi-tasking
 software, but don't understand the issues involved in writing re-entrant
 code, providing tasking-safe data structures, or real-time software in
 general).


I've been involved in the proposed design for an Ada widget set.
It ended up coming surprisingly close to the Xt single inheritance
model minus the added features of Xt/Motif such as the event translation
manager, keyboard traversal, etc... (due to $$$ considerations :-)

(BTW, the Ada9X inheritance proposal is a near duplicate of
the Xt single inheritance model -- It's how we've done it for years
in a more formalized definition, that's all).  Not that I'm saying the
Xt inheritance model is *great* but it's how you do it by hand in
a language which doesn't support inheritance.  (ie. it's optimally sufficient)

MOTTO: Do not what has been done, but understand it and use it.


-- 
John Goodsen
goodsenj@ajpo.sei.cmu.edu

-- 
John Goodsen
goodsenj@ajpo.sei.cmu.edu
From: ae@sei.cmu.edu (Arthur Evans)
Newsgroups: comp.lang.ada
Subject: Re: how pure are functions?
Date: 7 Apr 92 15:23:48 GMT
In-reply-to: csa09@seq1.keele.ac.uk's message of 7 Apr 92 10:46:13 GMT
cc: csa09@seq1.keele.ac.uk

csa09@seq1.keele.ac.uk (P. Singleton) asks about the purity of Ada
functions.

In a word, they aren't.

The concept of "value-returning procedure" existed in an early Ada
design (about 1980 or so) but disappeared in the final version.  The
only vestige that remains is that parameters of functions must have
mode "in"; "in out" and "out" are not permitted.

As for your specific questions:

    Are "functions" prohibited from accessing or altering global
    variables?
No, no such restriction.

    Are they free from internal state?
No.

    Are they "functions" in the mathematical sense?
No.

    Are their calls referentially transparent?
No.

    Does anyone care?!
Yes, but not the way I expect you want.  There was some attempt to move
Ada 9X even further away from functional purity by permitting them to
have "in out" or "out" parameters.  The current revision document has no
such provision.

Note, for example, that an Ada function can return a (pseudo-)random
number, or a value read from an input file.

Art Evans
----------------------------------------------
Arthur Evans, Jr, PhD           Ada Consultant
461 Fairview Road
Pittsburgh PA  15238-1933
412-963-0839
ae@sei.cmu.edu
From: deane@vaxc.cc.monash.edu.au
Newsgroups: comp.lang.ada
Subject: TeleUSE/Ada/Xwindows
Date: 10 Apr 92 04:02:47 GMT

Any experience in the use of the Telesoft TeleUSE/Ada product ? 
This currently is only available on SunSPARC platforms.  It consists of the
TeleUSE/C prototype tool, Telesoft Ada development environment, Ada bindings to
the TeleUSE run-time routines, and Ada bindings to Xlib, Xt, and Motif.
Any information would be appreciated.

In particular I am interested in portability of the code and suggestions to
improve the portability of code across different compilers, machines, and
operating systems.  I am also interested in problems and solutions to Ada
multitasking, support for multiple physical screens, and effort involved to 
write widgets to add to TeleUSE.
 
We wish to use a prototyping/development tool to develop and test a
user-interface for an OTH radar system.  Ada has been specified as the language
that must be used, and X-windows/Motif has been chosen for the presentation
component.  The interface has a large component which will have to be written
directly using Xlib.  Portability of the interface is important because we will
not choose the target hardware for another 2 years.  Speed of the final
interface is also an issue.  So far we have looked at a number of tools of
which TeleUSE, TAE+, Screen Machine which appear to be best suited to our
application.  Any other good development/prototyping tools ???



Newsgroups: comp.lang.ada
From: srctran@world.std.com (Gregory Aharonian)
Subject: Re: Open comment to Ted Holden
Organization: The World
Date: Thu, 9 Apr 1992 15:24:04 GMT

Sam,
	Maybe Ted is unsuccessfully trying to say that while Ada is more
safe and reliable to program in than other computer languages and commercial
software products (which is a very desirable for the military), it is not
more cost effective (that is, with different policies, other languages or
off-the-shelf stuff can be used and still meet mission requirements).
	I do not believe that Ada is more cost effective to program in than
other languages, and I do not believe that anyone can prove that it is,
given the poor understanding of software microeconomics inside the DoD, and
the lack of large enough amounts of cost data and models to prove so. Thus
many of the public posturings about Ada's great cost benefit are of little
worth.  Defend Ada because it is a safer language to program in, not because
of the cost economics.  Maybe that what Ted is saying.
	A point in his favor, though, is that military specifications and
procedures are excessive.  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. Also,
many commercial systems developed in other languages successfully handle
commercial mission critical tasks, for example, the programs that handle the
transactions of the stocks, commodities and international monetary exchanges,
each day handling tens of billions of dollars.

	Throwing money at Ada as a very safe, reliable system for mission
critical systems is justifiable, giving the lives and freedoms at stake.
Doing so because Ada is more cost-effective is a silly attempt by socialists
to act like captilists.  No one cares, as long as they defend the country.

Greg Aharonian
Source Translation & Optimization
Newsgroups: comp.lang.ada
From: eriks@lin.foa.se (Erik Svensson FOA2)
Subject: Re: associate functions to objects
Keywords: function, object
Organization: FOA, Linkoping, Sweden
Date: Thu, 16 Apr 1992 07:57:01 GMT

consp10@bingsunb.cc.binghamton.edu (Julian Insan Kamil) writes:

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

If you're going to use generics you can send a procedure or a function as an
argument when you instantiate (sp?) the package. 

(this is from the top of my head, so there might be some errors)
generic
	type Type_1 is (<>);
	type Type_2 is private;
	with procedure Foo(a : in out Type_1); -- Your supplied procedure
package Bar is
	procedure Foo_Bar(Some_Parameter : in Type_2);
end Bar;

then in your package body:

package body Bar is
	
	procedure Foo_Bar(Some_Parameter : in Type_2) is
	begin
		.
		.
		Foo(some_other_parameter);
		.
		.
	end Foo_Bar;
end Bar;

You instantiate this with
	procedure a_procedure(a : Type_2); -- Declare your procedure
	procedure a_procedure(a : Type_2) is -- the body
	begin
		(some code)
	end a_procedure;

	package My_Bar is new Bar(A_Type,another_type,a_procedure);

Simple as that. 
It's in LRM 12.1.3, 12.3.6.

>-Julian Insan Kamil
>Computer Consultant at SUNY-Binghamton
>email: consp10@bingsunb.cc.binghamton.edu
>email: consp10@bingvaxu.cc.binghamton.edu
--
Erik Svensson			Research Officer
Guided Weapons Division		National Defense Research Establishment (FOA)
Stockholm			Sweden

net.address: 	eriks@fenix.lin.foa.se

&& This .sig is protected by SIGinfectant(tm). Look for the &&, a sure sign of
quality .sig protection. &&
From: mes@aplpy.jhuapl.edu (Mark E. Schmid)
Newsgroups: comp.lang.ada
Subject: non-blocking I/O on Unix workstations
Summary: Req. for info. on tools / techniques for non-blocking I/O
Keywords: Ada I/O tasking sockets
Date: 10 Apr 92 17:33:57 GMT


 I suspect this has been discussed before, so references to previous
postings are welcome.

Anyway, the basic problem is that I'm faced with developing
multi-tasking Ada programs on a Unix workstation.  I need to do 
various forms of I/O, including terminal I/O, file I/O (logging),
and socket based communication to other workstations.  
At the moment, I'm working with VADS as a compiler, but am not 
particularly tied to it.

I realize that it may be debatable whether to pin blocking I/O
behavior on the Ada run-time or the underlying O.S.  I'm really
not trying to start up that issue - I'm just trying to find ways
to deal with the current state (i.e. SOLUTIONS!). 

Can anyone comment on:
	1) compilers that run on mainstream Unix systems that
	just flat out provide non-blocking I/O for standard Ada
	I/O calls.

	2) compilers that provide special run-time facilities that
	enable users to create their own non-blocking I/O facilities.
	(and sketches on how this is done)

	3) general (compiler independent) techniques that might be
	used to deal with a system that wants to block on I/O.


				Thanks in advance,
				Mark Schmid
				mes@aplpy.jhuapl.edu
From: edmunds@vaxr.llnl.gov
Newsgroups: comp.lang.ada
Subject: Re: Why ADA?
Date: 16 Apr 92 18:37:33 GMT
Organization: LLNL_LIS


 I wrote --
 | 
 | than any other I've used (when I say "learn", I don't mean just being
 | able to coerce it to write Pascal-Ada, or FORTRAN-Ada, or whatever).
 |   4.  *Everyone* I know who has learned Ada after knowing C says that
 | their C programming has improved significantly by having been "forced"
 | to use Ada's features.
 | 
 
 bds@maui.linus.mitre.org (Barry D. Smith) writes:
 > 
 > First, it would appear from the above quote that writing C-Ada is bad,
 > but writing Ada-C is good.  This seems a little ethnocentric.  Each
 > language would seem to have its own features, and "good" programming
 > in that language is defined as much by that language's culture as by
 > anything else.  For example, I once had some people contributing to a
 > fairly large Lisp program.  These people were very good C programmers,
 > but had not programmed in Lisp before.  Well, it wasn't much of a
 > surprise that their Lisp code was clearly stylistically C.  It worked
 > fine, but it ran against the grain.
 > 
	Well, each language may have its own features, but some languages
have more than others.  I found it took longer in Ada to internalize
the features like generics and exceptions to the point that I was using
them "elegantly", rather than trivially.
	I would say that Ada's "culture" has had more to do with what
the current thinking on what a "good" C program should look like than
what C's culture has....

 > Please continue to have these arguments.  I'm enjoying them immensely.
 > But don't worry too much about the future.  As they say, it'll be here
 > quick enough by itself.
 > 
	You're very right about keeping this all in perspective.  And
it's something anyone who's been around a while should be able to do, given
the changes demanded by Correct Programming even in the last 7 years.

-- Dave Edmunds
Newsgroups: comp.lang.ada
From: nwebre@polyslo.csc.calpoly.edu (Neil Webre)
Subject: Exceptions & McCabe Complexity
Date: Tue, 07 Apr 92 03:43:50 GMT
Organization: Cal Poly State Univ,CSC Dept,San Luis Obispo,CA 93407


Can someone point me to a reference(s) on how exceptions are treated
when computing the cyclomatic (mccabe) complexity of an Ada unit? I
have reasoned my way to one way of treating them, and then looked at
the McCabe metrics tools in the metrics directory of the ada archives
and found that they are treated the same way. However, I am uneasy
about some of my conclusions. I didn't use a formal approach in
reasoning.  I would like to read a more formal discussion of the
problem if one exists.

I checked CARL without result. Since it only goes back to 88,
perhaps there is some earlier work.

Neil Webre, Professor                               nwebre@zeus.calpoly.edu
Department of Computer Science                      FAX: (805) 756-2956
Cal Poly                                            TEL: (805) 756-1392
San Luis Obispo, CA 93407, USA
From: sampson@cod.NOSC.MIL (Charles H. Sampson)
Newsgroups: comp.lang.ada
Subject: Re: Open comment to Ted Holden
Date: 15 Apr 92 22:18:29 GMT
Article-I.D.: cod.3769
Organization: Computer Sciences Corporation

In article <1992Apr15.011200.28572@intellistor.com> wicklund@intellistor.com (Tom Wicklund) writes:

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

     In my experience (15+ years working for the Navy) this isn't strictly
true as stated.  The government has always accepted the use of tools that
contribute to the project.  The only problem is that the tools themselves
become part of the maintenance base; they must be maintainable for the
very long lifetime of the system.  (20+ years for a Navy system is not un-
reasonable.)  Often this is accomplished by requiring that the tools be
written in a maintainable language and be documented for maintainance ac-
cording to military standards.  When I was maintaining the Navy's CMS-2Y
compiler we had a tool that generated tables for manipulating the lan-
guage's keywords.  That tool was written in CMS-2Y.  On the other hand,
sometimes a project is willing to accept the use of a tool by baselining
a particular version of the tool, treating it as a black box.  In the
above example, the government might decide to obtain copies of a particu-
lar version of Lex and Yacc, making them a part of the project's toolset
for its life cycle.  This approach has the disadvantage that when the
tool misfires after 10 years there's nobody around who can fix it.

     Given those long life cycles and the large size of many military
systems, these approaches to controlling lifecycle maintenance are rea-
sonable.  In the past the military has relied on commercial software and
has often been stung, as when the company releases a new version of a
FORTRAN compiler, for example, which is not compatible with the previous
version, along with instructions about the source changes required to
to use the new version, and a notice that support for the old version is
being dropped.  On a large project that might mean life or death for some
people, source changes are not lightly made.

     I left the first paragraph in because I think it needs repeating,
perhaps daily.

				    Charlie
Newsgroups: comp.lang.ada
Subject: Again: Ada Software Engineering, Dayton OH
From: mtabacch@eve.wright.edu (Marci Tabacchi)
Date: 13 Apr 92 08:51:05 EST
Organization: Wright State University


PLEASE READ THIS NOTICE!!!!

Recently, I posted the following job notice:

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

or send your resume to 

		Larry Janning
		1321 Research Park Drive
		Dayton, Oh  45432
		

             
Let me elaborate a little:
(From a programmers point of view?)

This position is intended for certain types of individuals.  
Are you:
	1. Competent in software engineering?
	2. Academically inclined?
	3. Creative and enthusiastic?
	4. Fun to work with?

Do you:
	1. Like working on VERY large programs?
	2. Like to be recognised for doing a good job?
	3. Hate gossip and backbiting?
	4. Like challenges on a regular basis, and like
		mixing work with school?

Can you:
	1. Move to Dayton?
	2. Deal with Dayton? 
	3. Get a security clearance?


If this sounds like you, please let Larry know.  
P.S. to the persons who have responded: This is competition!!! :->


Incidently, the work environment is exceptional.  Larry is a decent
guy to work for.  The others engineers have all of the attributes above.
The company has avg. benefits, and good pay.  What is the best feature
is that you can take on as much *state-of-the-art* challenges as you
want and just go for it.  You can also enjoy flexible school
arrangements, and there is a school not .5 miles from the work site.

(Most of us attend school either in Masters or Phd.  SAIC will pay for
sensible programs as long as you get a good grade)
 


Disclaimer:  Any views here are strictly my own.  (That is why they 
can be trusted!!!)



marci
From: johnson@natasha.ics.Hawaii.Edu (Philip Johnson)
Newsgroups: comp.lang.ada
Subject: PD Unix Ada compiler needed
Date: 7 Apr 92 05:18:40 GMT
Organization: University of Hawaii, Department of Computer Science

A student in my comparative programming language course would like
to do her semester project in Ada.  Is there by any chance a public
domain Ada compiler available that I could download by anonymous
FTP?  

Please reply to me directly since I do not normally read this newsgroup.
Thanks very much for your help.

Philip Johnson

-----------------------------------------------------------------------
Philip Johnson                             johnson@uhics.ics.hawaii.edu
Assistant Professor
Collaborative Software Development Laboratory
Department of Information and Computer Sciences   
University of Hawaii
2565 The Mall                                            (808) 956-3489
Honolulu, HI 96822                                  Fax: (808) 956-3548