HDTenEightyP/NetNews huggingface dataset:
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: Open Systems closed to Ada?
Organization: Texas Instruments Inc
Date: Mon, 14 Dec 1992 17:09:30 GMT

In <92346.46129.LJ10891@LMSC5.IS.LMSC.LOCKHEED.COM> LJ10891@LMSC5.IS.LMSC.LOCKHEED.COM writes:

>   Fred, I lost count of the number of times you used the word "mandate" in
>your last post, but I gather that this is a pet peeve of yours.

>   In all seriousness, your implication that no one would use a non-validated
>Ada compiler, and therefore such a compiler has no value, seems suspect to me.

It may seem suspect, but take a look at who the major Ada customers
are, at least in this country.  If the government won't buy off on it,
companies probably aren't going to go to the effort of producing it.

>If you would briefly grant me the assumption that the mandate was being
>successfully enforced, would you agree with the statement that "No one can use
>any 'C' compiler, therefore 'C' compilers are useless"?  I doubt it.

No, because the major customer for C has no such 'mandate'.

>   I disagree with the Ada mandate; however, when all is said and done, the DoD
>is just one software customer.  I doubt there's a large market for Macintosh
>software at IBM.  It hasn't kept Mac programmers from peddling their wares
>elsewhere.  If the DoD chooses to freeze THEIR technology for eleven
>years at a pop, IT'S THEIR CHOICE (and, IMHO, one whose wisdom has yet to be
>established).

Yes, it's their choice.  And it stultifies the Ada market.


-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
Newsgroups: comp.lang.ada
From: stt@spock.camb.inmet.com (Tucker Taft)
Subject: Re: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)
Organization: Intermetrics Inc, Cambridge MA
Date: Fri, 11 Dec 1992 21:04:04 GMT

In article <1992Dec11.163811@lglsun.epfl.ch> 
  nebbe@lglsun.epfl.ch (Robb Nebbe) writes:

> . . .
>The problem with Ada is that it is a lot more difficult to do code generation
>in my head ;-) Some of you will scoff but my education is in computer
>engineering (thus hardware) and there is a tremendous amount a satisfaction in
>knowing what it is that I am telling the hardware to do and not just in the
>abstract sense.
>
>When I program in Ada this sense of satisfaction is just not there. Programming
>in C is sort of like making a piece of furniture yourself from scratch and
>programming in Ada is like buying a kit. 

I tend to agree with this assessment of Ada 83.

One of our goals for Ada 9X has been to give system programmers
back this feeling of satisfaction, so that you can do "code generation
in your head" for most Ada constructs.  In other words,
you can predict about how many machine instructions (and
generally which ones ;-) will be generated for each
construct in your program.  For a real-time embedded language,
this seems particulary important.

For example, an allocator in Ada 9X will be defined in terms
of a call on an appropriate Allocate procedure, user-replacable on
an access-type by access-type basis.
Similarly, a call on an instantiation of Unchecked_Deallocation
becomes a call on an appropriate user-replacable Deallocate routine,
preceded if appropriate by a call on a user-defined Finalize routine.

We have also provided the ability to create an access value
designating a declared variable, so long as it is marked "aliased,"
coupled with more control over by-reference vs. by-copy
parameter passing.

We also allow access to subprograms, allowing a pointer to
a procedure to be passed for the purpose of a call-back,
iteration over a data structure, etc.  This avoids some of
the heaviness and somewhat more-difficult-to-predict performance
of generics for certain simple situations.

Finally, the protected type feature is designed to allow
the construction of synchronization primitives with predictable
performance, including things like mailboxes, queues,
counting semaphores, etc.

Given some of these features, we hope that Ada 9X
will provide both the safety and high-level aspects
of Ada 83, but also the more "down-to-earth" feel appropriate for
systems programming, when you want it.

We would appreciate any specific suggestions about this 
issue of "control" or "predictability" of implementation
model, as it relates to systems programming in Ada 9X.

S. Tucker Taft     stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138
From: rlk@VisiCom.COM (Bob Kitzberger)
Newsgroups: comp.lang.ada
Subject: Language pitfalls (was Re: FORTRAN bug)
Date: 14 Dec 92 21:57:23 GMT

Experienced C programmers have rules of thumb that they follow in order
to help them to avoid language "problems".  Ada programmers also have
rules of thumb to help them avoid language "problems".  If you were to
list the top five C rules of thumb, they'd be something like:

	1. Use conditional preprocessor directives in .h files to avoid
           multiple file inclusions (oops!  That's a C preprocessor rule ;-)
 	2. Always use curly braces in conditionals
	3. Be careful to use '==' when you mean it, instead of '='
	4. Always malloc one more byte then your array length for strings
	5. Always use 'break' in each switch case, unless you really mean it

The top five rules of thumb for Ada are probably something like:

	1. Don't get carried away using tasks as units of decomposition
	2. Don't use the predefined types; define your own types
	3. Use packages as units of decomposition.
	4. Use private types to hide implementation details
	5. Avoid the USE clause; consider RENAMES instead.

Note that the Ada rules of thumb are more geared towards programming
in the large, and reflect the fact that the Ada programmer spends less
time on annoying *run-time* syntax glitches (*), and more time on
encapsulation and decomposition issues.

	.Bob.

(*) Of course, Ada programmers spend more time with compile-time syntax
    errors than anyone else ;-)
----------------
Bob Kitzberger          VisiCom Laboratories, Inc.
rlk@visicom.com         10052 Mesa Ridge Court, San Diego CA 92121 USA
                        +1 619 457 2111    FAX +1 619 457 0888
Newsgroups: comp.lang.ada
From: obry@flash.bellcore.com (Pascal Obry)
Subject: Re: C++ vs. Ada -- Is Ada loosing?
Organization: /u/obry/.organization
	<172@fedfil.UUCP>
Date: 14 Dec 92 11:35:17


He is up again.
Please, can somebody unplug him !

he/it seem to have some processes control problems.

--

-------------------------------------------------------------------------------
--  Pascal OBRY								     --
--  Room 2D-337				e_mail : obry@bellcore.com  	     --
--  Bellcore								     --
--  445 South Street			voice : 1 - 201 829 4039	     --
--  Post Office Box 1910		FAX   : 1 - 201 829 5981	     --
--  Morristown, New Jersey 07962-1910					     --
-------------------------------------------------------------------------------

  `` inheritance is surely a good answer, but who knows the question ? ''
From: frank@evax2.engr.arizona.edu (Frank Manning)
Newsgroups: comp.lang.ada
Subject: Re: Gunslingers
Date: 16 Dec 92 04:31:29 GMT
Reply-To: frank@evax2.engr.arizona.edu
Distribution: world,local
Organization: University of Arizona, College of Engineering and Mines, Tucson

In article <SRCTRAN.92Dec13230757@world.std.com> srctran@world.std.com
(Gregory Aharonian) writes:

>Finally, after the soldier threw Chester into the clock, it cost more tax
>dollars to pay for fixing the clock. Of course no one found out who the
>soldier was, they never stick around long enough to take responsibility for
>the cost of fixing clocks. Last I heard, the soldier (I think he was a
>sergeant named York) got a job at the Supplies, Arms, Indians and Cowboys
>stores that always seem to set up shops outside the forts.

Well, the historical records are not entirely clear on this subject. A few
historians maintain Sgt York was in fact Sgt York Manning, a chronic
malcontent who had recently been transferred to Fort Zemeckis from Fort
Lowell, Arizona Territory.

There was evidence that before he could be arrested on the charge of
assaulting a civilian, Manning went berserk and threw himself off the
Eastwood Ravine Bridge to avoid listening to any more religious wars about
firearm safety.

-- Frank Manning                                   -- Std disclaimer
-- College of Engineering and Mines                --
-- Civil Engineering 100, University of Arizona    --
-- Tucson, AZ  85721  frank@evax2.engr.arizona.edu --
From: klausf@akela.informatik.rwth-aachen.de (Klaus Frank)
Newsgroups: comp.lang.ada
Subject: Re: Online manual using editor tags
Date: 17 Dec 92 09:16:39 GMT
Organization: Student CS, RWTH Aachen
Distribution: world
NNTP-Posting-Host: akela.informatik.rwth-aachen.de

anderson@dseg.ti.com (John Anderson) vrites:

>Does anyone know of an online version of an Ada tutorial or manual
>that is implemented in a way similar to  a hypertext application?

You can use the 'tag' feature of the UNIX editor 'vi' or the GNU
browser 'less' to simulate hypertext links.  If your compiler adds
error messages with references to the LRM as comments to your source
code, you can look up the chapter referred to (recursive if your vi
supports tagstacks) and return to the source code within a few
keystrokes.  You can also use words occurring in the error messages or
the LRM itself as 'links' to the glossary using command '^]' and follow
the references found therein.

Please reply by mail if you want me to post a vi tagfile (using search
strings) for the LRM.  (Does anybody know if line numbers can be
searched for more efficient? Does vi use Boyer-Moore fixed string
search?).

You can find a similar tagfile for GNU Emacs on wsmr-simtel20.army.mil
in directory pd7:[ADA.GNU-ADA-MODE] named LRMTAGS.NUL.2 . Emacs tag
files contain search strings (chapter headings) and absolute text
positions.  For documentation on Emacs tags, visit node 'Tags' in the
Emacs Info system.

--
In 'vi reference, Version 8', Maarten Litmaath <maart@nat.vu.nl> writes:

>   Warning: some vi versions don't support the more esoteric features

    Tag commands:  (possible rhs for macros, e.g. ':map T :tag ')
>    :ta <name>              | Search in the tags file[s] where <name> is
>                            |   defined (file, line), and go to it.
>    ^]                      | Use the name under the cursor in a `:ta' command.
                             |   (But e.g.'3.3.3' is not recognized
                             |   as a single name).
>    ^T                      | Pop the previous tag off the tagstack and return
>    ^^                      | Edit the alternate (normally the previous) file.

    Relevant vi variables:
>    taglength=<*>           | The number of significant characters in tags
>                            |   (0 = unlimited).
>    tags=<string>           | The space-separated list of tags files.
     tagstack                | Enable tagstack feature
Newsgroups: comp.lang.ada
Subject: Why HOL?
From: mshapiro@netlink.cts.com (Michael Shapiro)
Date: Wed, 16 Dec 92 19:42:15 PST
Organization: NetLink Online Communications, San Diego CA

Why is Ada called a "High Order Language" (HOL) instead of a
"High Level Language" (HLL) like nearly every other language
I've seen described?

Among explanations I've heard were:

"The DoD likes to order people around, but doesn't want to level
with them."

"Many language studies have measures that measure the level, giving
a continuous range of numbers (c.f., Halstead Numbers).  The DoD
doesn't allow this concept and wants things they can count, not measure.  
Hence they went with a counting concept of order."

"Because they thought they were inventing something new with Ada and
didn't want to use anyone else's jargon."

------

Can anyone help me with the real insights for this terminology question?


--                    
INTERNET:  mshapiro@netlink.cts.com (Michael Shapiro)
UUCP:   ...!ryptyde!netlink!mshapiro
NetLink Online Communications * Public Access in San Diego, CA (619) 453-1115
Newsgroups: comp.lang.ada
From: sampson@nosc.mil (Charles H. Sampson)
Subject: No NULL Statement
Organization: Computer Sciences Corporation
Date: Wed, 16 Dec 1992 18:42:20 GMT

In article <1992Dec15.203558.18211@inmet.camb.inmet.com> stt@spock.camb.inmet.com (Tucker Taft) writes:
>
>   In retrospect, one could argue that it would have been better
>   to have no "null" statement at all (other than simply ";") than
>   to create a situation allowing this kind [example deleted] of
>   one word error.

     The problem being discussed was a result of the overloading of
NULL in Ada.  IMO, there's too much overloading of reserved words in
Ada in an effort to minimize the number of reserved words.  (For those
who don't know, keeping the number of reserved words down was a design
requirement.)  However, denoting a null statement by the absense of a
statement is not the way to go, as Mike Feldman's example from C illus-
trates.  I worked for many years in another language that also had this
"feature".  I was amazing how many times the statement controlled by
an IF would vanish by the careless insertion of an unneeded statement
terminator.  The associated debugging problems were severe.

     Furthermore, an explicit null statement clearly says, "At this point,
do nothing."  For those of us who believe in readability, this is impor-
tant.

 				Charlie
From: ryer@inmet.camb.inmet.com (Mike Ryer)
Newsgroups: comp.lang.ada
Subject: Multi-way Case Statement
Date: 15 Dec 92 17:35:05 GMT
Organization: Intermetrics Inc, Cambridge MA

Here's another way to get the affect of multi-way case:

  type Three_Cases is (F_F_F, F_F_T, F_T_F, F_T_T, 
                       T_F_F, T_F_T, T_T_F, T_T_T);

  Truth_Table: constant array (Boolean, Boolean, Boolean) of Three_Cases := 
       (((F_F_F, F_F_T), (F_T_F, F_T_T)), 
        ((T_F_F, T_F_T), (T_T_F, T_T_T)));
begin
    . . .

  case Truth_Table(a>b, c/=d, e<f) is
    when F_T_F | F_T_T => ...

    when T_T_F | T_F_F => ...

    when T_T_T => ...

    when others => ...

  end case;

Once you set up the two top declarations, you can code as many 3-way case
statements as you like, without repeating them.  I suspect that the ultimate
generated code is the same as what you would get if it were a built-in
language feature.

Mike Ryer
Intermetrics
Newsgroups: comp.lang.ada
From: eachus@oddjob.mitre.org (Robert I. Eachus)
Subject: Re: Open Systems closed to Ada?
Organization: The Mitre Corp., Bedford, MA.
	<1992Dec7.215946.18972@mksol.dseg.ti.com>
	<1992Dec9.052624.23020@seas.gwu.edu>
	<1992Dec11.131655.23725@mksol.dseg.ti.com>
Date: Fri, 11 Dec 1992 18:35:46 GMT


    I'm not going to quote any of Fred McCall's broken record,
especially since most of it just ain't so.  The DoD mandate says use
a validated Ada compiler.  The validation rules go on to say what
validation of an Ada compiler means.  It has never meant, and never
will mean strict conformance to a particular standard.  (Godel proved
that impossible quite a while ago.)  Validation sets a standard of
quality, and provides a process for determining whether a particular
deviation from the ACVC tests can be justified.

    In particular if a compiler vendor has an Ada compiler which
includes some Ada 9X features, or adds support for rate-monotonic
scheduling or what have you, it is not automatically rejected.
Instead, any deviations are evaluated to determine if the vendor's
justification is in fact acceptable.

    In practice the ARG acts as a court of last resort in such cases.
If the fast reaction team (FRT) or the ARG feels that an issue needs
further discussion, the validation certificate in question is issued,
and the test in question is withdrawn if necessary until the issue is
resolved.  Starting with ACVC 2.0, this process will be further
streamlined to encourage vendors to offer such (legitimate)
extensions, and also to allow vendors to release new technology
sooner.

    There have been cases where some members felt this was used by one
vendor or another as a sort of sneaky loophole, but others didn't.  In
this case the rule is effectively innocent unless unanimously found
guilty.  In other cases--even though the test was correct and the
compiler was wrong--a test was withdrawn because the ARG felt it was
counterproductive.  We even have a class of AI called pathology,
informally defined as "we'll tell the vendors what they should do, but
no user, and especially no ACVC test, should expect it to work that
way."

     So validation and the Ada mandate are NOT intended to stiffle
innovation or limit creativity.  They are intended to insure that long
lived source code is still useable ten years from now, without a lot
of support costs.  You don't like that, play in another sandbox.  I
can find you companies which mandate FORTRAN, C, C++, COBOL, and LISP,
but you probably wouldn't be happy with any of them.  The company
policy is there for the same reason as the DoD policy, and your
difficulty seems to involve having rules to enforce software
engineering standards.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
Newsgroups: comp.lang.ada
From: ae@sei.cmu.edu (Arthur Evans)
Subject: Re: Ada compiler wanted!
Organization: Software Engineering Institute
Date: Sun, 13 Dec 1992 15:24:32 EST

In response to my claim that the GNAT Project at NYU, which is
implementing an Ada compiler to be part of the FSF distribution, will
include a port to the Macintosh, emagnuso@halcyon.com (Erik Magnuson)
asks:
>> Is this really likely given the FSF antipathy to Apple? Do the GNAT
>> implementors feel bound by RMS request to boycott Apple and not
>> support GNU software on Apple?

It may be unlikely, but it's happening.  RMS is working closely with the
NYU folks on GNAT, and NYU is doing nothing without his agreement.  How
Dewar obtained RMS's agreement to the Mac port I don't know; what I do
know is that Dewar reports having obtained it.

Art Evans
Newsgroups: comp.lang.ada
From: accs1@bagheera.mumath
Subject: Re: Lets split comp.lang.ada into multiple groups to confine flames
Reply-To: accs1@bagheera.mumath
Organization: Sun Microsystems
Date: Thu, 17 Dec 92 08:47:27 GMT

In article 62879@mimsy.umd.edu, alex@cs.umd.edu (Alex Blakemore) writes:
>make comp.lang.ada obsolete and create a small set of groups instead.
>
>  some suggestions
>
>    comp.lang.advocacy   - for the flame wars
>    comp.lang.programmer - for discussions of design/development Ada language issues
>                           (or comp.lang.technical or better name?)
>    comp.lang.announce   - moderated, low volume important announcements
>                           of meetings, products, standards, new mandates :) etc
>    comp.lang.misc       - catch all
>
>this works well in the NeXT groups which I've been reading lately
>they have huge flame fests between Objective-C and C++ but confine
>them to the advocacy group.
>
>anyone interested or familiar with how to do this?
>
>P.S. For people worried about getting overrun by C++, stop worrying
>and do something to contribute to Ada's success instead of flaming.
>Does anyone else program in Ada on a NeXT using a DVORAK keyboard?
>Talk about swimming against the tide.
>
>-- 
>---------------------------------------------------
>Alex Blakemore alex@cs.umd.edu   NeXT mail accepted


I like the idea and the division as proposed sounds reasonable.
Frank
Newsgroups: comp.lang.ada
From: koehnema@enuxha.eas.asu.edu (Harry Koehnemann)
Subject: Re: Language pitfalls (was Re: FORTRAN bug)
Followup-To: comp.lang.ada
Reply-To: koehnema@enuxha.eas.asu.edu (Harry Koehnemann)
Organization: Arizona State University
Date: Wed, 16 Dec 1992 16:32:42 GMT

In article <EACHUS.92Dec15202249@oddjob.mitre.org> eachus@oddjob.mitre.org (Robert I. Eachus) writes:
>In article <1992Dec15.203558.18211@inmet.camb.inmet.com> stt@spock.camb.inmet.com (Tucker Taft) writes:
>
>   Oh boy.  That is a nasty one.  This argues for a "friendly" 
>   Ada compiler giving a warning about any use of "null;" other
>   than the idiomatic ones like "when others => null;" or "begin null; end;"
>   (especially in a function that returns an access type ;-).
>
>    Actually, there is an Ada rule which normally catches this, and
>which Robert Dewar and I have argued should be removed in Ada 9X.  (A
>function must contain a return statement RM 6.5(1).)  If it belongs on
>the top ten list, then the rule should stay.

The "null;"/"return null;" was a problem with the base case in a
recursive function (null is overloaded, and even worse it's an
expression *and* a statement - isn't that something we hate about
C :).  This implies there will be additional returns somewhere in
the routine and it will not be caught by the compiler.  The real
problem is that there exists an execution path that can lead out
of the function without encountering a return.  And, won't Ada
catch this at run-time?  Granted it would be nice for the language
to catch it at compile time, but the compiler could easily print a
warning saying that such a path exists.
--
Harry Koehnemann			Arizona State University
koehnema@enuxha.eas.asu.edu		Computer Science Department
Newsgroups: comp.lang.ada