Re: Ada vs C++

Re: Ada vs C++

[James B. White, III (Trey)]

The ability of C++ compilers to infer template instantiations may be
dangerous, but it allows the construction of incredibly powerful
interfaces. Combined with the ability to inline functions, you can write
strange constructions called "expression templates" and "template
metaprograms" that perform optimizations that are extremely difficult or
impossible for a compiler to perform on its own.

Ada may have advantages over C++, but only C++ allows these incredibly
powerful programming techniques. Unfortunately, the techniques are also
incredibly complicated and incredibly ugly. The resulting interface,
however, can be elegant. For more information, see the following
references by the inventor, Todd Veldhuizen.

<http://monet.uwaterloo.ca/blitz/#papers>

I would love for Ada to provide the same level of power, preferably in a
more elegant and straightforward way! 
-- 
James B. White, III (Trey)
Ohio Supercomputer Center
trey@osc.edu
<http://www.osc.edu/~trey/>
Phone: (614)292-9291  Fax: (614)292-7168

Re: Ada vs C++

[Robert Dewar]

James White says

<<The ability of C++ compilers to infer template instantiations may be
dangerous, but it allows the construction of incredibly powerful
interfaces. Combined with the ability to inline functions, you can write
strange constructions called "expression templates" and "template
metaprograms" that perform optimizations that are extremely difficult or
impossible for a compiler to perform on its own.

Ada may have advantages over C++, but only C++ allows these incredibly
powerful programming techniques. Unfortunately, the techniques are also
incredibly complicated and incredibly ugly.>>


So, we see from the above (if you believe it), that C++ is the way to
go if you want something that is incredibly powerful, incredibly complicated
and incredibly ugly.

Sometimes ones friends are ones worst enemies :-)

Seriously, I think this quest after "power" in languages, rather than
basic functionality, is misguided. An important ingrediant in achieving
reliability is to keep things simple at all levels.

You say that you can produce wonderful interfaces with this amazing
capability. What is interesting is to look at such an interface, and
then ask how that interface would be reflected and implemented in
other languages. Specific examples typically show that such claims
are simply inflated and have little substance!

Re: Ada vs C++

[Brian Rogoff]

On 5 Sep 1997, Robert Dewar wrote:
<... discussion of C++ template metaprograms deleted...>

> So, we see from the above (if you believe it), that C++ is the way to
> go if you want something that is incredibly powerful, incredibly complicated
> and incredibly ugly.

Lets not forget that there are lots of other features of C++ that interact to 
make it complicated and ugly, from an Ada perspective. So the experience of C++ 
templates, while helpful, is not entirely convincing. There are some good ideas 
in C++, though I agree that this (very specific case of embedding a little 
language in the template system) is not one of them. 

> Seriously, I think this quest after "power" in languages, rather than
> basic functionality, is misguided. 

I agree that you can waste a lot of time playing with features that may seem 
powerful but may end up not being worthwhile for practical development.
However, I don't know of any good way other than experience to decide what
is "basic functionality", and even then we'll always have disagreements
(modules, MI, assertions, ...).

> An important ingrediant in achieving reliability is to keep things simple 
> at all levels.

You are the last person in the world who needs to be reminded that the concept
of "simplicity" is heavily overloaded! 

What do you think about the idea of automatically instantiating generic 
subprograms by inferring parameters but *not* values, i.e., none of this 
"template metaprogram" stuff, but a simple :-) generalization of Ada 
overloading? Any difference in perspective as a user vs as a compiler writer? 

-- Brian

Re: Ada vs C++

[Larry Kilgallen]

In article <dewar.873461400@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> James White says
>
> <<

> Ada may have advantages over C++, but only C++ allows these incredibly
> powerful programming techniques. Unfortunately, the techniques are also
> incredibly complicated and incredibly ugly.>>

> Seriously, I think this quest after "power" in languages, rather than
> basic functionality, is misguided. An important ingrediant in achieving
> reliability is to keep things simple at all levels.

Real "power" makes it easier to shoot oneself in the foot.
With multiuser computers, one can even get the feet of neighbors.
"Power" seems the opposite of safety.

Larry Kilgallen

Re: Ada vs C++ (Expression Templates)

[James B. White, III (Trey)]

Robert Dewar wrote:
> You say that you can produce wonderful interfaces with this amazing
> capability. What is interesting is to look at such an interface, and
> then ask how that interface would be reflected and implemented in
> other languages. 

I have done exactly this. I started with a small sample calculation used
as an example in an article on expression templates. I implemented the
example in Ada using many techniques. I'll be giving a talk at Tri-Ada
on the results.

> Specific examples typically show that such claims
> are simply inflated and have little substance!

This is what I hoped to prove! I *wanted* to show that these ugly
expression templates were either unnecessary or easier to implement in
Ada. Unfortunately, neither was the case. In my field, high-performance
computing, an order of two difference in performance is significant. For
Ada implementations that created the desired interface, the execution
times were more like three times those of C++ with expression templates.
And the nature of the example calculation would tend to minimizes
differences between compilers, so other examples could perform even
worse!

In other fields, the relative priority of performance versus ease of
development isn't so skewed towards performance. I, however, am in the
unfortunate situation where the performance benefits of expression
templates probably outweigh the other benefits of Ada over C++.


-- 
James B. White, III (Trey)
Ohio Supercomputer Center
trey@osc.edu
<http://www.osc.edu/~trey/>
Phone: (614)292-9291  Fax: (614)292-7168

Re: Ada vs C++ (Expression Templates)

[Matthew Heaney]

In article <3413FFA6.D4D@osc.edu>, "James B. White, III (Trey)"
<trey@osc.edu> wrote:


>In other fields, the relative priority of performance versus ease of
>development isn't so skewed towards performance. I, however, am in the
>unfortunate situation where the performance benefits of expression
>templates probably outweigh the other benefits of Ada over C++.

I have only a reading knowledge of C++.  Can you explain what an
"expression template" is?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Ada vs C++

[Jon S Anthony]

In article <Pine.SGI.3.95.970904201703.13590A-100000@shellx.best.com> Brian Rogoff <bpr@shellx.best.com> writes:

> > Ada may have advantages over C++, but only C++ allows these incredibly
> > powerful programming techniques. Unfortunately, the techniques are also
> 
> I believe you can do all of this stuff with Common Lisp macros.  

Actually, CL macros seem much more generally capable than C++
templates.  For one thing, they aren't tied to the type system.  For
another, they can avail themselves of the full capabilities of CL
(including closures).  And, I still think you could write the C++
template facility (such as it is) in CL macros as an embedded langauge
(not that this would actually be useful or worth anything - just a
demonstration).  It would likely even be relatively straightforward,
but to be fair, I haven't looked at the possibility that closely.


> automatic instantiation, but that won't be able to do what you want. What 
> *you* want seems to be macros. Most Ada-philes seem to be macro-phobic,
> but don't let that stop you. 

Right.  I'm pretty skeptical of macros (real ones ala' CL) in
something like Ada (or C++ or anything like them).  They just don't
seem to fit the spirit of the language.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Ada vs C++

[Richard A. O'Keefe]

"James B. White, III (Trey)" <trey@osc.edu> writes:
>Ada may have advantages over C++, but only C++ allows these incredibly
>powerful programming techniques.

False.  Lisp people know this kind of meta-programming as a very old
technique indeed.

-- 
Unsolicited commercial E-mail to this account is prohibited; see section 76E
of the Commonwealth Crimes Act 1914 as amended by the Crimes Legislation
Amendment Act No 108 of 1989.  Maximum penalty:  10 years in gaol.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Ada vs C++ (vs Lisp)

[James B. White, III (Trey)]

Richard A. O'Keefe wrote:
> 
> "James B. White, III (Trey)" <trey@osc.edu> writes:
> >Ada may have advantages over C++, but only C++ allows these incredibly
> >powerful programming techniques.
> 
> False.  Lisp people know this kind of meta-programming as a very old
> technique indeed.

Let me clarify my statement. The combination of expression templates
*and* operator overloading *and* function inlining *and* efficient
compilers allows the creation of elegant interfaces that result in code
that rivals optimized hand-coded FORTRAN in performance. As far as I
know, this is true only of C++. If it is true of Lisp or anything else
(like Ada), I'd like to know!

-- 
James B. White, III (Trey)
Ohio Supercomputer Center
trey@osc.edu
<http://www.osc.edu/~trey/>
Phone: (614)292-9291  Fax: (614)292-7168

Re: Ada vs C++ (vs Lisp)

[Brian Rogoff]

On Mon, 8 Sep 1997, James B. White, III (Trey) wrote:
> Richard A. O'Keefe wrote:
> > "James B. White, III (Trey)" <trey@osc.edu> writes:
> > >Ada may have advantages over C++, but only C++ allows these incredibly
> > >powerful programming techniques.
> > 
> > False.  Lisp people know this kind of meta-programming as a very old
> > technique indeed.
> 
> Let me clarify my statement. The combination of expression templates
> *and* operator overloading *and* function inlining *and* efficient
> compilers allows the creation of elegant interfaces that result in code
> that rivals optimized hand-coded FORTRAN in performance. As far as I
> know, this is true only of C++. If it is true of Lisp or anything else
> (like Ada), I'd like to know!

I think it is obvious that you can't do this stuff with Ada generics
because Ada generic instantiation is not primitive recursive function
calculation (what a mouthful, was that clear?). Lisp macros can do 
arbitrary computation during expansion, so given a decent Lisp compiler 
you should be able to get the same effect. Ask nicely on the Lisp newsgroup 
and I bet you'll even get code.

My question is whether it is necessary for your purposes to have this
capability directly supported in the language, or if some source to source 
transformation tool would suffice; i.e., an Ada aware macro system or some 
other such tool. I recall reading about such a macro system (M5?) but I 
forget where...

(In case anyone missed it, the C++ techniques being discussed can be found 
 at http://monet.uwaterloo.ca/blitz/ ) 

-- Brian

Re: Ada vs C++ (Ada 0X)

[James B. White, III (Trey)]

Brian Rogoff wrote:
> I think it is obvious that you can't do this stuff with Ada generics
> because Ada generic instantiation is not primitive recursive function
> calculation (what a mouthful, was that clear?). 

Clear. More about this below.

> Lisp macros can do
> arbitrary computation during expansion, so given a decent Lisp compiler
> you should be able to get the same effect. Ask nicely on the Lisp newsgroup
> and I bet you'll even get code.

Finding code is easy. The trick is finding a decent Lisp compiler!

> My question is whether it is necessary for your purposes to have this
> capability directly supported in the language, or if some source to source
> transformation tool would suffice; i.e., an Ada aware macro system or some
> other such tool. I recall reading about such a macro system (M5?) but I
> forget where...

If it's supported in the language, it is portable. Before anyone starts
slamming the portability of C++ and templates, realize the situation has
changed dramatically over the last few months.

> (In case anyone missed it, the C++ techniques being discussed can be found
>  at http://monet.uwaterloo.ca/blitz/ )

I guess my real point is the following. Expression templates in C++
demonstrate a level of functionality absent from Ada. If the Ada
standard is updated again (Ada 0X?), perhaps the Ada community should
consider ways of including the capabilities of expression templates (and
template metaprograms) in the new standard. I certainly don't advocate
supporting C++-style templates. What I would like to see is the
*capabilities* of these techniques added to Ada, but with a better
implementation.
-- 
James B. White, III (Trey)
Ohio Supercomputer Center
trey@osc.edu
<http://www.osc.edu/~trey/>
Phone: (614)292-9291  Fax: (614)292-7168

Re: Ada vs C++ (Ada 0X)

[Brian Rogoff]

On Tue, 9 Sep 1997, James B. White, III (Trey) wrote:
> Brian Rogoff wrote:
> 
> > My question is whether it is necessary for your purposes to have this
> > capability directly supported in the language, or if some source to source
> > transformation tool would suffice; i.e., an Ada aware macro system or some
> > other such tool. I recall reading about such a macro system (M5?) but I
> > forget where...
> 
> If it's supported in the language, it is portable. Before anyone starts
> slamming the portability of C++ and templates, realize the situation has
> changed dramatically over the last few months.

Well, "portable", like "simple", is overloaded. If you had (for example) an 
Ada aware macro processor written in Ada 95 (so it can be ported), why is 
that not portable? Bob Duff comments that it would interfere with other 
tools, which is true, but I guess I was thinking of ways to solve your 
problem before "0X". 

> I guess my real point is the following. Expression templates in C++
> demonstrate a level of functionality absent from Ada. 

I think this level of functionality was deliberately omitted from Ada. 
Perhaps the ban on "macro" like features should be re-examined.

> I certainly don't advocate  supporting C++-style templates. 

Whoa, C++ style templates have lots of things in common with Ada generics, 
and some other things in common with macros. Whether this is unification or
confusion I don't know. Some of the aspects of C++ templates which are for 
parametric polymorphism, say especially automatic instantiation of generic
subprograms :-), seem like they make sense in an Ada context. Consider the
following relaxations of Ada rules (which have *nothing* to do with the
macro stuff)

(1) The name of a generic subprogram is allowed to appear anywhere that a
    non-generic subprogram name is allowed.

(2) Non-generic subprograms may overload generic ones.

(3) A subprogram component of a generic package may appear anywhere that
    a non-generic subprogram name is allowed.

(4) A generic package name may be specified in a "use" clause, allowing
    subprogram components to be specified without qualification according
    to (3).

(5) Some or all real parameters may be omitted in an explicit instantiation.
                                                                                
These relaxations of restrictions would be in the spirit of the C++
template mechanism, yet they wouldn't allow the kind of macro-like
computing you are discussing. Ada generics strike me as being a mechanism
for parametric polymorphism, not macro instantiation, so I would hope any 
Ada 0X proposal you want to try out on the net would not try to stuff 
all sorts of compile time computation onto generics. OTOH, I see no problem 
with changes to allow automatic instantiation, at least not in the sense of 
doing violence to Ada generics.

-- Brian

Re: Ada vs C++ (Ada 0X)

[Ole-Hjalmar Kristensen FOU.TD/DELAB]

"James B. White, III (Trey)" <trey@osc.edu> writes:

> 
> 
> Brian Rogoff wrote:
> > I think it is obvious that you can't do this stuff with Ada generics
> > because Ada generic instantiation is not primitive recursive function
> > calculation (what a mouthful, was that clear?). 
> 
> Clear. More about this below.
> 
> > Lisp macros can do
> > arbitrary computation during expansion, so given a decent Lisp compiler
> > you should be able to get the same effect. Ask nicely on the Lisp newsgroup
> > and I bet you'll even get code.
> 
> Finding code is easy. The trick is finding a decent Lisp compiler!
> 
> > My question is whether it is necessary for your purposes to have this
> > capability directly supported in the language, or if some source to source
> > transformation tool would suffice; i.e., an Ada aware macro system or some
> > other such tool. I recall reading about such a macro system (M5?) but I
> > forget where...
> 
> If it's supported in the language, it is portable. Before anyone starts
> slamming the portability of C++ and templates, realize the situation has
> changed dramatically over the last few months.
> 

Don't bet on that. We still have template classes which are legal C++,
but which in practice can only be compiled by CenterLine CC (and
probably other Cfront derivates), but not by g++, and not by Sun CC,
because of different strategies for instantiating the templates.

> > (In case anyone missed it, the C++ techniques being discussed can be found
> >  at http://monet.uwaterloo.ca/blitz/ )
> 
> I guess my real point is the following. Expression templates in C++
> demonstrate a level of functionality absent from Ada. If the Ada
> standard is updated again (Ada 0X?), perhaps the Ada community should
> consider ways of including the capabilities of expression templates (and
> template metaprograms) in the new standard. I certainly don't advocate
> supporting C++-style templates. What I would like to see is the
> *capabilities* of these techniques added to Ada, but with a better
> implementation.
> -- 
> James B. White, III (Trey)
> Ohio Supercomputer Center
> trey@osc.edu
> <http://www.osc.edu/~trey/>
> Phone: (614)292-9291  Fax: (614)292-7168

Re: Ada vs C++ (Ada 0X)

[Anonymous]

On 10 Sep 1997 13:28:47 +0200, ohk@tfdt-o.nta.no (Ole-Hjalmar Kristensen
FOU.TD/DELAB) wrote:

> "James B. White, III (Trey)" <trey@osc.edu> writes:
..
> > Brian Rogoff wrote:
..
> > If it's supported in the language, it is portable. Before anyone starts
> > slamming the portability of C++ and templates, realize the situation has
> > changed dramatically over the last few months.
> > 
> 
> Don't bet on that. We still have template classes which are legal C++,
> but which in practice can only be compiled by CenterLine CC (and
> probably other Cfront derivates), but not by g++, and not by Sun CC,
> because of different strategies for instantiating the templates.

"Legal C++"? Since there is no C++ standard, legal C++ is whatever a
compiler that calls itself a C++ compiler supports. To look at it
another way, every "C++" compiler supports a different language.

Ada: The only internationally standardized OOP language.


Jeff Carter  PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"English bed-wetting types."
Monty Python & the Holy Grail

Posted with Spam Hater - see
http://www.compulink.co.uk/~net-services/spam/

Re: Ada vs C++ (Ada 0X)

[Ole-Hjalmar Kristensen FOU.TD/DELAB]

nobody@REPLAY.COM (Anonymous) writes:

> 
> On 10 Sep 1997 13:28:47 +0200, ohk@tfdt-o.nta.no (Ole-Hjalmar Kristensen
> FOU.TD/DELAB) wrote:
> 
> > "James B. White, III (Trey)" <trey@osc.edu> writes:
> ..
> > > Brian Rogoff wrote:
> ..
> > > If it's supported in the language, it is portable. Before anyone starts
> > > slamming the portability of C++ and templates, realize the situation has
> > > changed dramatically over the last few months.
> > > 
> > 
> > Don't bet on that. We still have template classes which are legal C++,
> > but which in practice can only be compiled by CenterLine CC (and
> > probably other Cfront derivates), but not by g++, and not by Sun CC,
> > because of different strategies for instantiating the templates.
> 
> "Legal C++"? Since there is no C++ standard, legal C++ is whatever a
> compiler that calls itself a C++ compiler supports. To look at it
> another way, every "C++" compiler supports a different language.
> 

Well, that's exactly the problem with C++. Istead of just "legal", I
should have said "legal according to the draft ISO standard".

> Ada: The only internationally standardized OOP language.
> 

Yes.

> 
> Jeff Carter  PGP:1024/440FBE21
> My real e-mail address: ( carter @ innocon . com )
> "English bed-wetting types."
> Monty Python & the Holy Grail
> 
> Posted with Spam Hater - see
> http://www.compulink.co.uk/~net-services/spam/

Re: Ada vs C++ (vs Lisp)

[Robert A Duff]

In article <Pine.SGI.3.95.970908203001.11288C-100000@shellx.best.com>,
Brian Rogoff  <bpr@shellx.best.com> wrote:
>My question is whether it is necessary for your purposes to have this
>capability directly supported in the language, or if some source to source 
>transformation tool would suffice; ...

The problem is that such a tool would probably not be standard, and
would probably get in the way of other tools.

- Bob

Re: Ada vs C++

[Joerg Rodemann]

James B. White, III (Trey) (trey@osc.edu) wrote:

> The ability of C++ compilers to infer template instantiations may be
> dangerous, but it allows the construction of incredibly powerful
> interfaces. Combined with the ability to inline functions, you can write
> strange constructions called "expression templates" and "template
> metaprograms" that perform optimizations that are extremely difficult or
> impossible for a compiler to perform on its own.

> Ada may have advantages over C++, but only C++ allows these incredibly
> powerful programming techniques. Unfortunately, the techniques are also
> incredibly complicated and incredibly ugly. The resulting interface,
> however, can be elegant. For more information, see the following
> references by the inventor, Todd Veldhuizen.

I wonder how this will work on non-standard highend machines. As far as I
can see --- if all you need is 
   a) very high computational power (number crunching)
   b) use of already existing numerical libraries
   c) good support by the vendor
on such machines you most of the time are left with f77 or maybe f90 or even
HPF. Perhaps the C compiler does work properly too. If you use C++ and
desire at least a bit of portability forget about nested librarie and i.e.
templates. Template instantiation still seems to be a serious problem for
compiler writers her --- and although normal desktop machines are already
capable of get this thing right...on the highend machines I worked on this
left us with a real mess. Sure, there are workarounds available but they
neither increase readability nor are they portable at all (all those pragmas
concerning instantiation.) The more complex your templates are the more likely
is it that they will fail.

On desktop machines I think this power hunting does not make much sense. A
factor of 2 or 3 in speed is clearly serious but only if you intend to
run the code for a long time (months to years). Otherwise a gain in
shorter development time may prove much more important than anything else.
(I saw people spending weeks with number crunching just to throw away the
results because the discovered a missing - in -= or a = instead of a ==
or some similiar silly bug. (Many were related to memory leaks and faulty
vector access. Multi-dimensional arrays are not that easy in C as one would
guess. :-) ). Those template constructs seem be similarly errorprone to me.
And --- which debugger will help you there?

Sorry for my sceptical view here, it's of course just my opinion.

Yours

Joerg


--
rodemann@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann
Phone: ++49-(0)711-5090670     | Flurstrasse 21, D-70372 Stuttgart, Germany
-------------------------------+---------------------------------------------
rodemann@rus.uni-stuttgart.de  | University of Stuttgart, Computing Center
Phone: ++49-(0)711-685-5815    | Visualization Department, Office: 0.304
Fax:   ++49-(0)711-678-7626    | Allmandring 30a, D-70550 Stuttgart, Germany

Re: Ada vs C++ (high-performance libraries)

[James B. White, III (Trey)]

Joerg Rodemann wrote:
> I wonder how this [expression templates] will work on non-standard highend machines.

High-end C++ compilers are now starting to handle templates quite well
-- KCC (www.kai.com) and Cray C++, for example. The techniques use only
(draft) standard C++. Indeed, C++ compilers of the recent past have been
nowhere near the standard, but because of all the investment in C++,
things are moving *very* quickly. 

The whole point is that you *can* (or *will*) get portable
high-performance. You can build portable optimizations into the template
library that you can't build into Fortran libraries -- or even Fortran
compilers!

As you say, there are issues of complexity and debugging. But the
additional effort in development and quality control may be worth it for
high-performance computing -- particularly if this extra effort appears
at the level of library development and not application development. 

-- 
James B. White, III (Trey)
Ohio Supercomputer Center
trey@osc.edu
<http://www.osc.edu/~trey/>
Phone: (614)292-9291  Fax: (614)292-7168

Ada vs C++

[Lao Xiao Hai]

There is a very interesting discussion on
comp.lang.c++.moderated regarding Ada
versus C++ for safety-critical software.
Some readers of this forum might find it
stimulating.

Richard Riehle
AdaWorks Software Engineering
richard@adaworks.com
http://www.adaworks.com

Re: Ada vs C++

[Colin Paul Gloster]

Lao Xiao Hai wrote:
"There is a very interesting discussion on
comp.lang.c++.moderated regarding Ada
versus C++ for safety-critical software.
Some readers of this forum might find it
stimulating.

Richard Riehle
AdaWorks Software Engineering
richard@adaworks.com"

Thank you very much. I am a member of the Association of C &
C++ Users ( HTTP://WWW.ACCU.org/ ) and subscribe to some of its
high quality email lists but do not these days look at the newsgroups
for
C and C++ nearly as much as accu-general (the main ACCU list).

For those of you trying to find the thread Lao Xiao Hai alerted us to,
the
initial post is news:bebbba07.0107191159.47311f81@posting.google.com
timestamped 19 Jul 2001 18:40:10 -0400 and started by
18k11tm001@sneakemail.com (Russ) on news:comp.lang.c++.moderated

Regards,
Colin Paul Gloster

Ada vs C++

[Ray Diederich, 301-869-8400]

From _Defense_&_Aerospace_Electronics_, Vol. 1, Num. 1 (June 24, 1991), a
quote from Lloyd Mosemann, deputy assistant secretary of the Air Force,
regarding the yet to be released case studies of Ada versus C++:

"Without Exception Ada won out in all categories of study," said Mosemann.
He said Ada's cost savings were 35% over C++'s, and maintenance savings
topped 70%.

(Reprinted without permission.)

Ray Diederich
**********
My employer would prefer that I had no opinions to express, especially any
that may have been expressed here.
**********