HDTenEightyP/NetNews huggingface dataset:
From: emery@dr_no.mitre.org (David Emery)
Subject: Re: Programs wanted
Organization: The Mitre Corp., Bedford, MA.
Date: Tue, 26 Jan 1993 01:57:37 GMT

Consider 
  package P is
	type I1 is new integer;
	-- "+" now redefined for objects of type I1
	function "+" (l :I1; r : integer) return I1;
	function "+" (l: integer; r : I1)  return I1;
  end P;

  with P; use P;
  procedure Q is
    X, Y : I1 := 1;
    I, J : Integer := 2;
    MAGIC_NUMBER : constant := 42;
  begin
    X := X + I;
    X := X + 1;
    X := MAGIC_NUMBER + Y;
    Y := X + J;
    I := integer(X) + integer(Y);
  end Q;

How many unique operators are there in this code???  Almost any answer
to this question involves enough semantic analysis to resolve Ada
overloading.  That's a good-sized chunk of an Ada compiler.  

				dave
Newsgroups: comp.lang.ada
From: walkerj@ajpo.sei.cmu.edu (John Walker)
Subject: Winter 91-92 AdaIC Newsletter
Summary: available electronically
Organization: Ada Information Clearinghouse
Date: Wed, 27 Jan 1993 14:47:55 EST

You can now get an electronic copy of the Winter 91-92 issue of the Ada
Information Clearinghouse Newsletter.  It's on the AJPO host
(ajpo.sei.cmu.edu) as file n-92-12.hlp in the public/adanews directory.

Note: This electronic version will be available in advance of the hardcopy
mailed to subscribers.  The issue has been unavoidably delayed because of
changes in procedures for printing.  We regret any inconvenience, and we
expect that the Spring issue should come to you at its regular time.

           ----------------------------------------------------
        John Walker, AdaIC, 703/685-1477, walkerj@ajpo.sei.cmu.edu
 -The days of paper tape are over!  The 90s will be the decade of MYLAR!-
             All standard disclaimers apply -- with emphasis!


Newsgroups: comp.lang.ada
From: ryer@inmet.camb.inmet.com (Mike Ryer)
Subject: Re: ASIS (Was Re: IrisAda)
Organization: Intermetrics, Inc.
Date: Thu, 21 Jan 1993 20:57:19 GMT


Bear in mind that ASIS has a cost beyond the dollars you pay for it.  It
can result in slower compilers and larger program libraries.

Our compiler (for MVS) currently generates DIANA; it would be a very simple
matter to add ASIS generation -- just send money.  However, I've been lobbying
in-house to scrub down the DIANA to a much simpler internal form, deleting a
lot of the attributes that are only there for use by future tools.  This would
make the compiler a lot faster and the libraries at least a factor of three
smaller.

Telesoft and Rational have technology which generates and retains a lot of
data in the libraries.  Providing an ASIS interface is convenient for them.
Vendors who have, or wish to have, leaner compilers may not be able to meet
the ASIS specification.  We estimate that supporting ASIS requires that the
compiler generate and retain over 1000 bytes of information per line compiled.

In my opinion, ASIS has been defined as "everything that Telesoft and Rational
happen to have in their libraries", rather than "everything that a reasonable
tool vendor needs and cannot easily compute for him/herself".

I'd rather see Ada compilers become as small and fast as C compilers than
see richer tool support.  ASIS precludes small and fast.  I'd rather see
Ada compilers get cheaper, instead of providing more functions.  ASIS will
cost something to implement; increase the size and complexity of the compiler
source code that has to be maintained; and, no doubt, create an additional
validation burden eventually; I think that small/fast/cheap would be better 
for the acceptance of Ada than ASIS support could ever be.

These are just my opinions -- I don't control the direction of Intermetrics'
compiler technology.  Our customers control it through their purchasing
habits.  If you talk to us, we'll tell you that ASIS support means slower
compilers and bigger libraries and let you make the tradeoff.  If you just
put it in your RFPs, standards, or regulations without asking the cost,
we'll comply, whatever the cost.

So please, don't jump on the ASIS bandwagon too fast.  At least wait until
more than one vendor implements it.  See how well it works on your PC's and
in your large projects.  Find out whether users turn the ASIS option off
in order to get their work done.  If ASIS's cost in size and speed are
acceptable, then it's a good thing.  But that is yet to be demonstrated.


Mike Ryer
Intermetrics
Newsgroups: comp.lang.ada
From: matwood%peruvian.cs.utah.edu@cs.utah.edu (Mark Atwood)
Subject: Ada spec of IEEE 488 GPIB ???
Date: 21 Jan 93 09:34:54 MST
Organization: University of Utah

I have just about finished, and am now working on my second Ada project
where we will be controlling intruments via an IEEE 488 bus.  I was
wondering, this cannot be unusual, especially in the ATE world.

Does there exist a "standard" binding to the IEEE 488 GPIB bus?

-- 
Mark Atwood                  :: Being a kitten is it's own excuse.
matwood@peruvian.cs.utah.edu :: 
The University has enough problems without being blamed for mine.
From: dritz@ANTARES.MCS.ANL.GOV (Ken Dritz)
Newsgroups: comp.lang.ada
Subject: Request pointers to research
Date: 26 Jan 93 20:50:13 GMT
Organization: The Internet

I'd like to become familiar with research in formal methods as related to Ada.
I would appreciate pointers (either posted to the net, or sent as email to me)
to work in

   o  formal semantics of Ada, particularly using denotational semantics
      (has the Esprit project in Europe touched on this?);
   o  verification, as related to proving the correctness of Ada
      programs or Ada compilers;
   o  deriving Ada from higher-level description languages.

Anything would help, but bibliographic references that I could track down would
be the most useful.

Thanks,
Ken Dritz (dritz@mcs.anl.gov)
From: maysee@ss2.af.mil (Eric E. Mays)
Newsgroups: comp.lang.ada
Subject: Re: Jovial J3B Compiler
Keywords: Jovial
Date: 27 Jan 93 13:52:55 GMT
Reply-To: $HOME@ss2.sews.wpafb.af.mil
Organization: U.S. Air Force

In article <1993Jan26.194204.22800@fcom.cc.utah.edu>, tcrook@u.cc.utah.edu (Tom Crook) writes:
|> I know this is the Ada group, but I don't know any better place to
|> post an inquiry about Jovial.  I am looking for contacts of people or
|> companies that might have knowledge or availability of Jovial J3b
|> compilers.  The place where I work when I'm not being a student has to
|> maintain F-16 A/B software.  The old SofTech compiler we have only
|> runs on IBM VM/CMS release 4 and IBM OS.  We need to try and find one
|> that would run under newer IBM releases or even on other platforms
|> such as VAX/VMS or Unix.
|> 
|> Even rumors might be useful at this point.  We've exhausted all leads
|> such as the Ada/JUG newsletter.  If you know someone who worked on J3B
|> compilers years ago, let me know.
|> 
|> Thanks
|> 
|> 
|> 
|> 
|> -- 
|>  /~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
|>  | Thomas Crook                  He that hath no beard is less than a man   |
|>  | tcrook@u.cc.utah.edu                            --William Shakespeare    |
|> /__________________________________________________________________________/

    Have you talked to Dale Lange at the Ada Jovial Validation Facility?

He may be able to help you?  I noticed you mentioned our newsletter in

your message, so you may have already spoken to him.

Thanks

--------------------------------------------------------------------------
Eric Mays                            Hope of Deliverance from the 
maysee@ss2.sews.wpafb.af.mil         darkness that surrounds us.
                                         -- Paul McCartney
--------------------------------------------------------------------------
From: erickson@taurus.cs.nps.navy.mil (David Erickson)
Newsgroups: comp.lang.ada
Subject: private types and recompilation
Date: 27 Jan 93 22:15:35 GMT
Organization: Naval Postgraduate School, Monterey

When Ada 83 was designed, why did the designers choose to put
the details of private types in package specifications, rather than
in package bodies (which is more in the spirit of information hiding, and
better supports independent compilation).

As it stands now, if I write a program that withs a package that specifies
private types, I must recompile that program if the details of the private 
types are modified, even if there is no change to the non-private 
specifications of the package.

For example, if a linked list implementation is chosen, a LIST package
might look like this:

generic
  type ATOM is private;
package LIST_ADT is
  type POSITION is private;
  type LIST is private;
  procedure CREATE(L: in out LIST);
  procedure INSERT_AFTER(L: in out LIST; P: POSITION; A: ATOM);
  ...

private
  type LIST;
  type POSITION is access LIST;
  type LIST is record
    A: ATOM;
    NEXT: POSITION;
  end record;
end LIST_ADT;


but a program that uses the LIST package does not see the details of the 
private types, so why should a change in those details, say to an array
implementation, cause the program to be recompiled.

The problem could be avoided if the private portion of the package was 
moved to the package body or if it could be declared "is separate".

-Dave Erickson
From: mab@wdl39.wdl.loral.com (Mark A Biggar)
Newsgroups: comp.lang.ada
Subject: Re: private types and recompilation
Date: 28 Jan 93 18:08:53 GMT
Organization: Loral Western Development Labs

In article <9301271722.aa25516@Paris.ics.uci.edu> kanderso@mabillon.ICS.UCI.EDU (Kenneth Anderson) writes:
>In comp.lang.ada you write:
>>When Ada 83 was designed, why did the designers choose to put
>>the details of private types in package specifications, rather than
>>in package bodies (which is more in the spirit of information hiding, and
>>better supports independent compilation).
>I'm not sure, but I think because the compiler needs to know the size
>of the types so that it can allocate space for parameters in the
>subprograms that are defined in the spec.
>>generic
>>  type ATOM is private;
>>package LIST_ADT is
>>  type POSITION is private;
>>  type LIST is private;
>>  procedure CREATE(L: in out LIST);
>>  procedure INSERT_AFTER(L: in out LIST; P: POSITION; A: ATOM);
>>  ...
>>private
>>  type LIST;
>>  type POSITION is access LIST;
>You only need the previous two lines.  The declaration below can be
>hidden in the body of the package.
>>  type LIST is record
>>    A: ATOM;
>>    NEXT: POSITION;
>>  end record;
>>end LIST_ADT;

Sorry but you can't do that because LIST is mentioned in the non-private
part of the package spec, its completing declaration must be included in the
private part.  It is only incomplete types that are first introduced in the 
private part that can be completed in the package body.  So if you wrote
the package like the following then you can push the completed type to the
body.  Besides the above package definition is clumsy anyway because the
abstraction for a linked list does not need both the node type and the access
to the node be externally visible.

generic
    type ATOM is private;
package LIST_ADT is
    type LIST is private;
    procedure CREATE(L: in out LIST);
    procedure INSERT(L: in out LIST, A: ATOM);
    ...
private
    type NODE;
    type LIST is access NODE;
end LIST_ADT;

package body LIST_ADT is
    ...
    type NODE is record
	A: ATOM;
	NEXT: LIST;
    end record;
    ...
end LIST_ADT;

Notice that the incomplete type NODE is only mentioned in the private part
of the spec so its completing declaration can wait until the package body.

--
Mark Biggar
mab@wdl1.wdl.lroal.com
From: bs@alice.att.com (Bjarne Stroustrup)
Newsgroups: comp.lang.ada
Subject: Re: Why and how do organizations select the OO
Date: 25 Jan 93 15:49:33 GMT
Article-I.D.: alice.24696
Organization: AT&T Bell Laboratories, Murray Hill NJ



mfeldman@seas.gwu.edu (Michael Feldman @ George Washington University) writes

 > The point was not to tar OO experts as windbags,

I didn't think you were, though of course SOME are.

 > but to comment on the
 > state of things. The customer in this case is thrashing around, has
 > little knowledge of what's happening in the field, and is making purely
 > political/religious statements. My distress came from the fact that
 > the organization didn't seem really interested in finding out more
 > or get really educated.

and that's the real rub. Many organizations and people are so busy
``getting the job done'' or jumping on some bandwagon that they don't
want to take the time to learn anything new.

The real power of languages that support techniques beyond what is
directly supported by C/Pascal is exactly those techniques.

Ada supports data abstraction and C++ data abstraction and object-oriented
programming (let's quibble about the meaning of those words elsewhere
if we must; their exact meaning isn't important to what I'm trying
to say here) and unless you take the bother learning those techniques
you are not going to get anywhere near the benefits from Ada/C++ that
you might.

One way of expressing this is that companies (and individuals) wants mere
training (i.e. ways of using new tools without absorbing new concepts).
What they need is education (i.e. new concepts and their related techniques).
Ada without some understanding of data abstraction, etc. seems to me to
be very nearly just Pascal, and C++ without some understanding of data
abstraction, etc. is just C with better type checking.

I don't know about the Ada world, but in the C++ world we do have a problem
with teachers and textbook writers who miss the connection between concepts
and programming language constructs and thus miss the point and makes learning
unnecessarily difficult for the students.

 > They were - as is so often the case -  arguing
 > from nontechnical starting points. There are pro-OO and anti-OO factions
 > in the group, neither being especially scientific. There is also a 
 > faction that believes the Ada mandate should be followed in their case,
 > and a faction that is working harder to evade the mandate that they
 > would need to work to follow it.

 > Their state of knowledge of OO truly seemed to be "It's that stuff that
 > C++ has and Ada doesn't." Some in the group were quite surprised to
 > discover (from me) that Ada supports information hiding and private types.
 > Their eyes glazed over when I got to the intricacies of inheritance.

Maybe you focussed too much on the intricacies and too little on the
concepts :-) I don't experience serious problems getting the object-
oriented concepts and the C++ language mechanisms that support then
across - the problem comes when the ideas have to be applied to real
projects (exactly, as for the data abstraction concepts and the language
constructs that support them).
From: beidler@guinness.cs.uofs.edu (Jack Beidler)
Newsgroups: comp.lang.ada
Subject: Re: REQ: CS2 Textbook Info. Needed
Date: 27 Jan 93 18:22:45 GMT
Organization: Department of Computing Sciences

I am not aware of any CS 2 books using Ada.  However, last year we
used Schneider and Bruell's new text from West Publishing Co.  The
book is written in a language independent style but with a
Pascal/Modula-2 flavor.  The book has several language supplements,
including an Ada supplement.  The supplement is very thin, but
can be enhanced with some Ada handouts.  We also encouraged our 
students to purchase a good Ada reference, like Cohen or Barnes.

Last year we received a DARPA grant to develop materials for this
course and the data structures course.  A PC disk containing those 
materials will be made available at the SIGCSE conference.  The
materials include

1.	A collection of data structure components (stacks, queues,
        lists, binary trees, n-ary trees, ...)
	The list and tree packages are dual paradign packages,
	supporting both the positional paradigm (a la the Stubbs and
	Webre data structures texts) and traditional LISP-like
	recursive paradigm.
2.	Laboratory Assignments, with support files.
3.	Several packages and pieces of code to support various
        CS 2 and CS 7 assignments.

We plan to use the text again this year, but we will modify the
syllabus to take better advantage of our Ada resources (e.g. more
separation between specs. and implementation details and in some cases
not get into implementation at all).

Regarding access types, we introduce them in CS 2 and give a lab.
assignment and one other assignment with them.  We prefer to give
a broader based CS 2 course and leave more of the access type
stuff for the CS 7 (data structures) course.
-- 
+------------------------------------------------------------------+
|  John (Jack) Beidler				                   |
|  Prof. of Computer Science Internet: BEIDLER@JAGUAR.UOFS.ED      |
|  University of Scranton              beidler@guinness.cs.uofs.edu|
|  Scranton, PA 18510	      Bitnet : BEIDLER@SCRANTON            |
|                                                                  |
|          Phone: (717) 941-7446	 FAX:   (717) 941-4250     |
+------------------------------------------------------------------+
Newsgroups: comp.lang.ada
From: bs@alice.att.com (Bjarne Stroustrup)
Newsgroups: comp.lang.ada
Subject: Re: Why and how do organizations select the OO
Date: 23 Jan 93 13:16:12 GMT
Article-I.D.: alice.24691
Organization: AT&T Bell Laboratories, Murray Hill NJ



mfeldman@seas.gwu.edu (Michael Feldman @ George Washington University) writes

    They hired a _really_ big-name consultant (NOT a professor, Mark!)
    to teach them his OO methodology and take a first crack at a design
    for them. After collecting a very large fee, he walked away from the
    project, leaving behind what they say is an unworkable design. 

I realize you probably can't name names, but it would be nice if you could
for two reasons. Firstly because charaltans ought to be exposed, secondly
because someone could misinterpret your statement into something condemning
lange groups of ``OO-experts'' as windbags who don't deliver. (there are
no shortage of windbags and self-proclaimed ``experts,'' but no one field
has a monopoly on them).
Newsgroups: comp.lang.ada
From: ae@sei.cmu.edu (Arthur Evans)
Subject: Re: DIANA (Was Re: ASIS (Was Re: IrisAda))
Cc: yow@sweetpea.jsc.nasa.gov
Organization: Software Engineering Institute
Date: Fri, 22 Jan 1993 17:26:58 EST

yow@sweetpea.jsc.nasa.gov (Bill Yow) asks how to get information about
DIANA.

The latest published version of DIANA is available in
    DIANA: An Intermediate Language for Ada (Revised Version)
    edited by G Goos et al
    Lecture Notes in Computer Science 161
    Springer-Verlag
    ISBN 3-540-12695-3
    ISBN 0-387-12695-3
The work reported was done at Tartan Laboratories in 1983.

A later revision was performed by Intermetrics, but as far as I can tell
the results of that work were never released by the government.

Art Evans
----------------------------------------------
Arthur Evans, Jr, PhD           Ada Consultant
461 Fairview Road
Pittsburgh PA  15238-1933
412-963-0839
ae@sei.cmu.edu
Newsgroups: comp.lang.ada
From: srctran@world.std.com (Gregory Aharonian)
Subject: Re: Comments on Ada vs. C++ panel
Organization: The World
Date: Fri, 22 Jan 1993 17:18:37 GMT


>>Last week there was a panel on Ada vs. C++ in Monterey.  Would anyone
>>who attended post a personal report on comp.lang.ada?

>No, please don't!!!

Yes, please do, especially if the panel discussed the economics aspects of
Ada and C++ market advocacy and policies vis-a-vis what is the best ways
to inevst(waste) tax dollars to push languages and mandates.

Greg Aharonian
Source Translation & Optimization
-- 
**************************************************************************
Greg Aharonian
Source Translation & Optimiztion
P.O. Box 404, Belmont, MA 02178
Newsgroups: comp.lang.ada
From: mfeldman@seas.gwu.edu (Michael Feldman)
Subject: Re: Why and how do organizations select the OO
Organization: George Washington University
Date: Tue, 26 Jan 1993 15:32:50 GMT

In article <1993Jan25.155937.10417@ennews.eas.asu.edu> koehnema@enuxha.eas.asu.edu (Harry Koehnemann) writes:
>
>Interesting.  I saw the same thing out here.  A friend of mine works at
>a company (also nameless) developing a very large real-time system.  There
>were many variables in this project  - new processor, new language (Ada),
>very large project, drastically reduced cycle time, and new development
>method (OO) - ie. lots of risk.  They had hired a consultant to help in
>specification and design who basically told them that "if you're going to
>use Ada, you have to use OO spec/design"  

This is fascinating, Harry. The received wisdom I seem to be hearing a
lot of seems to use the same words to make a different statement: "If
you're going to use OO spec/design, forget about Ada, because it doesn't
support multiple inheritance." Both statements are BS, of course.
>
>Of course, everyone followed the consultant.  Not because he was right
>(although he may have been), but because I'm sure no one in a decision
>making power really knew any better.  As you say it's kindof like
>religion - like the congregation following the preacher and assuming
>it's his responsibility to get them to heaven.

Amen to that, brother! It has always been thus, though. My sense of deja vu
gets exercised more and more these days. I lived through the 70's, and taught
through the latter half thereof. "Structured programming" was the subject
of a similar religious crusade. "No GOTO's!" "GOTO's!" "Lots of procedures!"
"Procedures are inefficient!" Etc., etc. Eventually our views matured
and the languages and hardware caught up. 

Managers are, by definition, less recently educated than worker-bees, and 
have more at stake, so they seem to be eternally vulnerable to consultants 
and other crusaders. This is not to trash managers - it's in the nature of 
things, I'm afraid. One does wish for a modicum of intellectual honesty,
though. Sigh...
>
>BTW, last I heard it's behind schedule and way over budget - imagine that.

Surprise.

>Too many variables for onw project.

Ah, now maybe we're getting down to the point.

Mike Feldman
Newsgroups: comp.lang.ada
From: breland@cobweb.mcc.com (Mark A. Breland)
Subject: Re: Why and how do organizations select th
Reply-To: breland@cobweb.mcc.com
Organization: MCC
Date: Mon, 25 Jan 1993 19:49:07 GMT

In article 24696@alice.att.com, bs@alice.att.com (Bjarne Stroustrup) writes:
>mfeldman@seas.gwu.edu (Michael Feldman @ George Washington University) writes
>
>> The point was not to tar OO experts as windbags,
>
>I didn't think you were, though of course SOME are.
>
>> but to comment on the
>> state of things. The customer in this case is thrashing around, has
>> little knowledge of what's happening in the field, and is making purely
>> political/religious statements. My distress came from the fact that
>> the organization didn't seem really interested in finding out more
>> or get really educated.
>
>and that's the real rub. Many organizations and people are so busy
>``getting the job done'' or jumping on some bandwagon that they don't
>want to take the time to learn anything new.

Careful now, the overtaxed people trying to get their job done usually
would give anything to learn something new that will ease their workload.
Unfortunately, they don't have the time due to the overload imposed
by management or other programmatic dilemmas.  However, I'll agree with
you that bandwagon-jumpers do tend to slide into new threads pretty
superficially without considering the conceptual ramifications.

---
Mark A. Breland - Microelectronics and Computer Technology Corporation (MCC)
Ada Fault Tolerance                               | voice:    (512) 338-3509
3500 West Balcones Center Drive                   | FAX:      (512) 338-3900
Austin, Texas 78759-6509   USA                    | internet: breland@mcc.com