Re: SOLVED! Decoupled Mutual Recursion Challenger

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <38pulp$ovg@oahu.cs.ucla.edu> jmartin@oahu.cs.ucla.edu (Jay Martin) writes:

   First that bug in your C program is a classic, worse than some of
my old PL/I implicit conversion horror stories!

   Second, let's put the package forward proposal in the trashcan it
deserves.  I'm not trying to be critical, but as one of those language
lawyers you want to shoot, the only feature it would add to the
language is to allow you to shoot yourself in the foot instead of
stopping you.  Ada, even Ada 83, has a perfectly good mechanism for
generating mutually recursive types, with operations which derive and
(in 9X) dispatch.  All you have to do is stick in a "extra"
derivation. (Or if you want apparent symmetry, two.)  Treat the extra
work exactly as it should be treated--as a warning that there is
complexity here which needs thinking about.

   All the hullaballo is about that required (and in some sense
arbitrary) symmetry breaking.  But as has been pointed out the
ordering is a feature of the language which no one should want to
throw away.  It is really a guarantee that no object's value is
referenced before it is created and (if it has an initial value)
initialized.  All the "clever" solutions ignore this.  When you look
at the way the bodies have to be written, all you have done is either
postphone the problem, or ask the programmer to solve it for the
compiler.

  > Ada83 was just handed over to the international standardization
  > organization and said, "Check the spelling and ratify it".

   This is a misunderstanding.  It took a lot of effort to insure that
there was a single Ada standard, and part of that effort involved a
translation of ANSI Ada into French. (ISO 8652 1987 is a one-page
endorsement of the ANSI and AFNOR standards.  With 9X the ANSI and ISO
standards will be the same document.)  But the effort that went into
converting Ada 80 (MIL-STD 1815) into a useable standard took more
than two years, and a lot of work worldwide by thousands of people.
Having a single small design team kept this from creating a camel, and
the same approach was taken for 9X.

  > This, in my opinion, is the only way that languages should be
  > standardarized.  Ada83 has been ruined because it has been set in
  > cement with even minor changes impossible.

  This is a total misunderstanding.  If you get a copy of the
Annotated Ada Reference Manual, you will find that almost every page
has an AI on it.  The terminology of "Ada Interpretation" and "Binding
Interpretation," was chosen due to the fact that standard maintenance
was not really supported by standards organizations a decade ago, but
the Ada maintenance procedures were used as a model in setting up the
current ISO procedures.

  > Language design is maintanance!  So it is trivially obvious that
  > the only way to do language design and maintanance is to have one
  > reasonable,dedicated and responsible individual have total power
  > and control (The IQ of a committee...).

    Consensus and a number of people with a vision of what the
language IS help a lot.  But no single individual can get it right
every time.  If you look at the AI's closely you will find that not
even a dedicated group of language lawyers can accomplish that.  But
there are relatively few AI's that correct other AI's, so we did
pretty well (at least in the final product).

  > Huh? Oops, by "Ada style language" I meant a completely different
  > language without upward compatibility problems.  Remove tasking,
  > exceptions, nesting, floating point types, discriminated records,
  > derived types, real models, fixed point types, blocks, goto, named
  > parameters, aggregates, slices, rep clauses, simplify
  > generics,etc, you can gain alot of simplicity.

    So remove all the features you don't need this week, and you have
a much smaller language.  Fine, no one is stopping you from using that
subset.  But the whole purpose of the Ada standardization effort was
to make it possible to take your code, and Joe's code, and Ralph's
code, and use them in the same program without migraines.  This
requires that subsets work with programs that use the pieces they
ingnore.  THAT is what orthogonality is about.

    A one page or even ten page program that used "all" of Ada would
be an abomination.  But Ada needs to be able to express any
programming construct so that the programmer can think about what is
the most appropriate technique to use in this application.  Removing
that would be a major disservice to serious programmers.

  > If you design a language that requires 200 IQ brainos who never
  > make errors to understand/use, then trying to use that language on
  > a project of a hundred average programmers is not going to be
  > successful.  Thus language design must be down to earth,
  > understandable and safe for the average programmer.  Spaced out
  > grandious languages is not what software developers need. I am not
  > saying this languages shouldn't be researched but practical
  > designs must also be studied.

   What we have in Ada is a language which is very easy for software
engineers to use without being punished for mistakes and oversights,
but without those bugs getting into the delivered product.

  Most software engineers regard the fact that there are many
programmers out there who don't understand software engineering and
therefore can't use Ada as an advantage.  But it would be even nicee
if someone could teach them software engineering!

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...