HDTenEightyP/NetNews huggingface dataset:
From: millerta@ucsu.Colorado.EDU (MILLER TIMOTHY A)
Subject: Survey on future of Object Oriented Programming
Organization: University of Colorado, Boulder
Date: Sat, 11 Apr 1992 17:47:37 GMT

Hi Guys:

I'm doing a Delphi survey on the future of the Object paradigm.
Please respond now, if you want to be included in this survey.
I will be sending out the same questions for a second round in two
days or when I have fifty responses. The second round consists of
the same questions, but it includes the average response and the
range of responses.

Please answer the following questions by responding with a specific
year (max 2050). You may answer these questions by editing this
message or appending the message with the question number
and response.

1) When will there be a  Object CASE tool that gains wide acceptance?

2) What year do you see OO Analysis techniques standardized?

3) What year do your see OO Design techniques standardized?

4) When will you be able to buy useful Objects "off the shelf" for custom
applications?

5A) When will Object Systems account for 30% of the applications being used?
5B) When will Object Systems account for 50% of the applications being used?
5C) When will Object Systems account for 80% of the applications being used?

6A) When do you expect that a background in Object Systems will be a
requirement for 30% of new hires for programming?
6B) When do you expect that a background in Object Systems will be a
requirement for 50% of new hires for programming?
6C) When do you expect that a background in Object Systems will be a
requirement for 80% of new hires for programming?

7) What OO language do you think will dominate by the end of this decade?


Sorry if this when out several times. There were several bugs some of
which are still not resolved.

Please reply to "timothy@eddie.rmnug.org".

Thanks

Tim
From: mrose@kali.stsci.edu (Mike Rose)
Newsgroups: comp.lang.lisp
Subject: packages
Date: 12 Apr 92 17:07:16 GMT
Reply-To: mrose@stsci.edu
Organization: Space Telescope Science Institute

I'm working on putting packages into some existing systems which don't
use them at all.  Are there any conventions for shadowing and
exporting symbols?  One case I'm looking at is to provide an alternate
definition of REDUCE (the one in Norvig's book that supports :key).
I don't want to replace common-lisp:reduce, but it's not clear if I
would be better off putting
  (shadow 'reduce)
  (export 'reduce)
in my file, or if it's better to put those in the defpackage.
What are the trade-offs here?

Also, CLtL2 pp269, discussing SHADOW, has the cryptic sentence
   Shadow should be used with caution.  It changes the state of the
   package system in such a way that the consistency rules do not hold
   across the change.
What does this mean?

Thanks,

Mike
--
Mike Rose, mrose@stsci.edu, 410-338-4949
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: Re: Lisp question
Date: 9 Apr 1992 22:34:19 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <4076@ucsbcsl.ucsb.edu> gene@ucsb.edu (Kostruba) writes:
>I have a Lisp question:

Just a suggestion: make your subject line more specific.  90% of the
messages in comp.lang.lisp are Lisp questions, so "Lisp question" is not
very useful.

>I have a function called changevar which accepts quoted lists as arguments:
>
>	(changevar '(x) '(varval varlist '(y)))
>
>The problem is, if I have variables with values symbol x and symbol y, how do
>I contruct the call to changevar?  If a has value 'x, and b has value 'y,
>the following is inadequate:
>
>	(changevar (list a) (list 'varval 'varlist (list b)))
>
>because x and y will not wind up as quoted.  How do I solve this problem?

If CHANGEVAR is a function, then it never sees the outer quotes.  The
arguments to a function are always evaluated, and both '(x) and (list a)
evaluate to the list (X).

However, the second argument to CHANGEVAR is indeed different in the two
cases, because of the *inner* quote in the list. '(varval varlist '(y))
evaluates to (VARVAL VARLIST (QUOTE (Y))), but (list 'varval 'varlist (list
b)) evaluates to (VARVAL VARLIST (Y)).  What you need to write is:

	(chargevar (list a)
		   (list 'varval 'varlist (list 'quote (list b))))

This kind of code is what backquote was invented to simplify.  Backquote
allows you to write a list that is "mostly" quoted, but then lets you
indicate where subforms should be evaluated.  Here's what your call looks
like with backquote:

	(changevar `(,a) `(varval varlist '(,b)))

The comma in a backquoted expression indicates those expressions that
should be evaluated.  For more information, see the appendix on backquote
in CLtL or CLtL2.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.lang.lisp
From: nbyoung@swen3 (Norm Young)
Subject: Re: regular expression matching under Lucid Lisp
Keywords: regexp regular expression lisp
Organization: University of Waterloo
Date: Wed, 8 Apr 1992 12:10:20 GMT

In article <1992Apr4.001545.28316@cs.cornell.edu> echris@cs.cornell.edu (E Christopher Lewis) writes:

 > I am looking for a robust regular expression matching system for use
 > under Lucid Common Lisp.  I have tried a few that seem experimental
 > at best.  Does any one know of a system that is reliable?  Any pointers
 > would be greatly appreciated.
 > 
 > Thanks - E

Check "Pragmatic Parsing in Common Lisp" by Henry G. Baker in
SIGPLAN Lisp Pointers v.IV, n.2, Apr-Jun 1991. I have used Baker's
technique, called "Meta", and have found it to be reliable and flexible.

Norm.

Software Engineering Group
Electrical and Computer Engineering
University of Waterloo
Newsgroups: comp.lang.lisp
From: fy@lucid.com (Frank Yellin)
Subject: Re: More informative prompt from Lucid CL
Organization: Lucid, Inc., Menlo Park, CA
	<KURODA.92Apr14210823@orc.msi.co.jp> <gdupq2G00jeiFHQ=ok@cs.cmu.edu>
Date: 15 Apr 92 16:32:17

FCC: ~fy/outmail.hold


In article <gdupq2G00jeiFHQ=ok@cs.cmu.edu> William.Lott@cs.cmu.edu writes:
>  ps: a neato hack that can be used if your implementation only has a
>  *prompt* object that it just prints is to set that to a structure and
>  make the structure print function do whatever you want.  You can do
>  all sorts of fun things with structure print functions if you have no
>  shame.

Wow!  Wonderful!  One of the best hacks I've seen in a while.

   (defstruct (prompt-hack (:print-function do-prompt)))
   (defun do-prompt (struct stream level) 
      (format stream "~A> " (package-name *package*)))
   (setq *prompt* (make-prompt-hack))

works in Lucid Common Lisp.  


-- Frank Yellin
   fy@lucid.com
Xref: sparky comp.lang.lisp:1321 comp.lang.postscript:2583
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.lisp,comp.lang.postscript
Subject: Re: Lisp dialect as front end to PostScript
Date: 7 Apr 1992 16:37:29 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com


Hmm, if you had a complete Lisp-to-Postscript translator written in Lisp,
and fed the translator to itself, you could then download the result to a
printer and then just send it Lisp code!

The nice thing is that Lisp and PS have many features in common, so the
mapping can be pretty straightforward.  Specifically, they both have
manifest typing and dynamic allocation with garbage collection.  The latter
is often the hardest part of any Lisp implementation, but the implementor
of this translator wouldn't have to worry about it.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.lang.ada
From: bds@maui.linus.mitre.org (Barry D. Smith)
Subject: Re: Why ADA?
Organization: The MITRE Corporation
	<11686.29d195cf@vms.eurokom.ie> <1992Apr15.115008.1@vaxr.llnl.gov>
Date: Thu, 16 Apr 1992 17:35:28 GMT


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


Although I read this news group a lot, I haven't participated because
I don't consider myself a very proficient Ada programmer.  However,
for what it's worth, I'd like to make a couple of comments on this
thread. 

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.

Second, a similar thread is taking place in comp.lang.lisp (with some
very cute quotes, like "Common Lisp is the Ada of the Lisp world.")  I
think these threads are very informative to me, and I hope they
continue, but I also hope that people don't take them too seriously.
Programming languages are like taxes, once created it takes an act of
God to get rid of them.  They do evolve, and these kinds of
discussions are helpful for this.  For example, look at FORTRAN-90,
and compare it to the FORTRAN-II I learned in the 1960's.  Or compare
Common Lisp with the Lisp of the 1950's, which didn't have
parentheses.  And don't let the arrogance of the C world get to you.
C is being replaced by C++ as we speak.  By the end of the millenia,
there will probably be a new language that will be all the rage.  And
the Ada world will probably be talking about the old days, when Ada
had no ...

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.

Barry Smith
From: ledwick@amsaa-cleo.brl.mil (Bill Ledwick)
Newsgroups: comp.lang.ada
Subject: Ada LRM
Keywords: LRM
Date: 8 Apr 92 19:05:06 GMT
Article-I.D.: amsaa-cl.6963
Distribution: na
Organization: U.S. ARMY MATERIEL SYSTEMS ANALYSIS ACTIVITY (AMSAA), APG, MD.

Is the Ada LRM available in electronic form (i.e. ftp site)?
				Thanks,
				Bill
From: adainfo@ajpo.sei.cmu.edu (Michele L. Kee )
Newsgroups: comp.lang.ada
Subject: AJPO Announcement - ACVC 1.11 Extended Life
Keywords: AJPO, ACVC 1.11, Compiler, Validation, Ada 9X
Date: 14 Apr 92 16:13:45 GMT
Organization: Ada Information Clearinghouse


The following article is being posted for the Ada Joint Program Office.

----------------------------------------------------------------------
			  AJPO ANNOUNCEMENT

ACVC 1.11 EXTENDED LIFE

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

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

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

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


John P. Solomond
Director
Ada Joint Program Office
From: hannahp@topaz.ucq.edu.au
Newsgroups: comp.lang.ada
Subject: Parallel Numeric Algorithms for MIMD Machines
Date: 15 Apr 92 11:30:11 AET
Organization: University of Central Queensland, Australia


Does anyone know of any source code for basic numerical operations freely
available for ADA.

For example, matrix operations, vector operations, row reduction, inverse, etc.

Any code, or an address of an appropriate FTP site would be appreciated.



Thanks in advance.


Paul Hannah.
From: mfeldman@milton.u.washington.edu (Michael Feldman)
Newsgroups: comp.lang.ada
Subject: Re: how pure are functions?
Keywords: referential transparency
Date: 8 Apr 92 02:01:13 GMT
Organization: University of Washington, Seattle

In article <2489@keele.keele.ac.uk> csa09@seq1.keele.ac.uk (P. Singleton) writes:
>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?!

There is no direct way in Ada to get a value-returning procedure. You
are correct in what you heard. Function parameters are limited to
IN mode; procedures can also have OUT and IN OUT. So from the point
of view of the parameter profile, functions are "pure."

Functions are free from internal state in the sense that all their
local variables are automatic. There is no equivalent to C's "static"
local variables.

Functions are NOT, however, prohibited from referencing nonlocal objects.
Indeed, a common Ada idiom is to wrap a package around a function so that
its state variables can be declared in the package body without being visible
to _callers_ of the function. This was debated in the 79-83 period before
the standard was adopted, and (I presume) this was deemed preferable to
static local storage.

I don't recall the definition of "referential transparency." Remind me.

Mike Feldman

-------------------------------------------------------------------------------
Michael B. Feldman                       co-chair, SIGAda Education Committee

Visiting Professor 1991-92               Professor
Dept. of Comp. Sci. and Engrg.           Dept. of Elect. Engrg. and Comp. Sci.
University of Washington FR-35           The George Washington University
Seattle, WA 98105                        Washington, DC 20052

mfeldman@cs.washington.edu               mfeldman@seas.gwu.edu
(206) 632-3794 (voice)                   (202) 994-5253 (voice)
(206) 543-2969 (fax)                     (202) 994-5296 (fax)
-------------------------------------------------------------------------------
From: hasan@emx.utexas.edu (David A. Hasan)
Newsgroups: comp.lang.ada
Subject: loop indices
Date: 17 Apr 92 17:01:53 GMT
Organization: UTexas Center for Space Research

I have a question about looping which in one sense is
stylistic but is also significant from the point of view
of the code efficiency.

Suppose I have a matrix manipulation routine which must
loop over the elements of several different ARRAYs.
My question stems from the observation that unless the
ARRAYs have the same bounds on their indices, I won't
be able to index into all of them using a single FOR-LOOP
index. Consider this example: 

   DECLARE
      TYPE Vector IS ARRAY( Positive RANGE <> ) OF Integer;
      p1 : CONSTANT Positive := 21;
      p2 : CONSTANT Positive := 51;
      size : Natural := 5;

      v1 : Vector( p1 .. (p1+size-1) );
      v2 : Vector( p2 .. (p2+size-1) );
   BEGIN
      FOR i IN 1..size LOOP
         v2(i) := v1(i);      -------------------(!)
      END LOOP;
   END;

Obviously, I'll have constraint error problems here.
The problem is not solve, either, if I replace the FOR
LOOP by 
   FOR i IN v2'RANGE LOOP
since the index *still* won't work in <v1>.
This problem gets even more complex (although qualitatively
similar) when the ARRAYs in question have multiple
dimensions or perhaps even differenty TYPEs.  In particular,
this issues is one which would arise for anyone trying
to implement a vector/matrix package in which the exported
TYPEs are unconstrained.

My approach to the problem is to do this:

     i1 : v1'RANGE;
     i2 : v2'RANGE;
   ...
     i1 := v1'FIRST;
     i2 := v2'FIRST;
     FOR i IN 1..size LOOP
        v2(i2) := v1(i1);
        IF i<size THEN
          i1 := Positive'SUCC(i1);
          i2 := Positive'SUCC(i2);
        END IF;
     END LOOP;

I could also use an EXIT WHEN to avoid incrementing <i1>
and <i2> at the end of the last pass.  This step is crucial
in order to avoid incrementing the indices outside their
respective ranges.  It seems to me that something like
this is inevitable, and I am curious whether there is an
approach which is preferable from an execution speed point
of view.

ps. One might argue that <i1> and <i2> could be declared as
Integers, which in this case would allow them to be
incremented outside the ranges of <v1> and <v2>, but this
begs the question.  In the case of generics, an "enclosing"
types like this is not necessarily available.

Any ideas (on what must be an well understood problem) will
be appreciated.

Thanks.
From: edmunds@vaxr.llnl.gov
Newsgroups: comp.lang.ada
Subject: Ada vs. C++ Paper (was Re: Why ADA?)
Date: 16 Apr 92 21:12:00 GMT
Organization: LLNL_LIS


    In an earlier post I mentioned an article by Fred Wild of Cadre
Technologies discussing the relative merits of Ada and C++.  I have since
received a lot of requests to post it, and since I didn't write it I
felt it best to talk to the man himself.  It is published in the 1989
Tri-Ada Proceedings, so anyone with access to them can find it there (the
complete title is "A Comparison of Experiences with the Maintenance of
Object-Oriented Systems: Ada vs. C++").  He was disinclined to post it,
since it theoretically is not "his" to publish anymore.
    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.  Fred *strongly* recommended a book by Scott Meyers
called "Effective C++ : 50 Specific Ways to Improve Your Programs and
Designs" (Addison-Wesley 1992).  The book apparently guides you around many
subtle pitfalls, and Fred feels that it would be well worthwhile for
anyone to read before attempting much in C++.  Fred said that they use
C++ at Cadre, and it has been well suited to many of their graphical user
interface problems, but that it requires very competent, very well-trained
programmers.
    He also told me a quote from Bjarne Stroustrup to the effect of --
"In C++ it's harder to shoot yourself in the foot, but when you do, you
blow off your whole leg."

-- Dave Edmunds
From: nedervol@schaefer.math.wisc.edu (Eric Nedervold)
Newsgroups: comp.lang.ada
Subject: Re: Open comment to Ted Holden
Date: 9 Apr 92 15:53:34 GMT
Article-I.D.: schaefer.1992Apr9.155334.20536
Organization: Univ. of Wisconsin Dept. of Mathematics

SAHARBAUGH@ROO.FIT.EDU writes:
>  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.

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

--Eric Nedervold
From: adainfo@ajpo.sei.cmu.edu (Michele L. Kee )
Newsgroups: comp.lang.ada
Subject: Ada 9X Receives International Go-Ahead
Keywords: Ada 9X
Date: 8 Apr 92 21:24:58 GMT
Organization: Ada Information Clearinghouse


             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.